Please create kubernetes/klog (for forking glog)

[dims]

New Repo, Staging Repo, or migrate existing

Import https://github.com/dims/klog into kubernetes org

Requested name for new repository

klog

Which Organization should it reside

kubernetes

If not a staging repo, who should have admin access

@dims @thockin

If not a staging repo, who should have write access

@tallclair @justinsb, @erictune @lavalamp

If a new repo, who should be listed as approvers in OWNERS

@tallclair @justinsb, @erictune @lavalamp @dims @thockin

If a new repo, who should be listed in SECURITY_CONTACTS

@dims @thockin

What should the repo description be

Leveled execution logs for Go (fork of https://github.com/golang/glog)

What SIG and subproject does this fall under in sigs.yaml

sig-architecture

Approvals

Please prove you have followed the appropriate approval process for this new
repo by including links to the relevant approvals (meeting minutes, e-mail
thread, etc.)
Discussion in sig-arch on Oct 25, 2018 ( http://bit.ly/sig-architecture )

Authoritative requirements are here: https://git.k8s.io/community/github-management/kubernetes-repositories.md

tl;dr (but really you should read the linked doc, this may be stale)

• If this is a core repository, then sig-architecture must approve
• If this is a SIG repository, then this must follow the procedure spelled out
  in that SIG's charter

Additional context for request

Any additional information or context to describe the request.

/area github-repo

[dims]

Also started an email thread in sig-arch:
https://groups.google.com/d/msg/kubernetes-sig-architecture/wCWiWf3Juzs/hXRVBH90CgAJ

[erictune]

/lgtm

[tallclair]

Are we still intending for this to be a transitional step towards our logging end goal? If so, can we call that out in the description & readme, and discourage others from using this? My concern is that as soon as we put out a "kubernetes-log" repo, other projects will start cargo-culting it...
Along similar lines, I wonder if we should stick with "glog" for the name? It further emphasizes that this is a fork of glog, and not a new kubernetes-endorced log library. It also means fewer lines need to be touched in the migration.

[cblecker]

hey @dims, can you ping me back on this when consensus at sig-arch has been achieved? Then I can coordinate with you on a repo transfer.

[dims]

Will do. thanks @cblecker.

I am going to assume @thockin and @tallclair are approvers on the plan from @kubernetes/sig-architecture-feature-requests

[dims]

/sig instrumentation

[dims]

@kubernetes/sig-architecture-feature-requests @thockin @bgrant0607 @tallclair @justinsb sig-arch folks, please +1 this request

[jdumars]

/lgtm

[lavalamp]

/lgtm

[erictune]

/lgtm

[BenTheElder]

Very interested in seeing this happen -- Minor note about glog vs klog, klog sounds a lot like clog which is perhaps not the greatest association for logging? :^)
If we are just doing a glog fork, k8s.io/glog might be good enough and easier to swap with dep etc.

[thockin]

@dims thoughts on @BenTheElder's comment?

[thockin]

/lgtm
/approve

[dims]

@BenTheElder @thockin klog gives us some wiggle room which can be valuable. we can still use dep + wrapper over klog ( like https://github.com/dims/glog-minimal ) when needed. So let's go with klog for now please.

[dims]

/assign @cblecker

[cblecker]

@dims So this isn't going to be a staging repo, right? Just moving over your existing fork? If so, can you please add me as an admin of the existing repo.

[dims]

Ack @cblecker doing that now

[justinsb]

/lgtm

[jbeda]

/lgtm

[tallclair]

/lgtm
I like the idea of putting the glog-compatible interface under k8s.io/klog/glog, so that 1) only the import lines need to touched, and 2) it is easy to tell which files have been migrated to the new logging interface (once we get to that).

[dims]

@tallclair affirmative! will do

[cblecker]

This is moved into https://github.com/kubernetes/klog . Haven't fully finished all the automation pieces, but it's in progress :)

[neolit123]

hm, so we forked glog in https://github.com/kubernetes/klog, but forked yaml in https://github.com/kubernetes-sigs/yaml. 🤔

@dims @cblecker what was the reason for the separate orgs for these brand new forks?

[dims]

@neolit123 that was my call. klog's initial sponsor was sig-arch and the code was coming from a trusted org so i felt it was ok to bring it directly into the main kubernetes org. the yaml one was coming from a personal github repo (ghodss) and it was coming in under sig-api-machinery, so it seemed better to leave it under kubernetes-sigs.

[cblecker]

@dims Can you add this to sigs.yaml? Then we can close this out.