Use a forked version of glog in kubernetes

[dims]

Based on the discussion in SIG-Arch on Oct 25 and previous experiment in #69333, we should start by forking glog, cleanup the code to suit our use cases and switch over to it. Also see issue #61006

Tasks:

• Request a new repository for the forked code in https://github.com/dims/klog in the kubernetes org(?)
• Update k8s.io/klog README.md to explain it is a permanent fork.
• update github.com/kubernetes/repo-infra/kazel/kazel.go to use klog
• update k8s.io/gengo/ to use klog
• update k8s.io/kube-openapi/ to use klog
• update github.com/google/cadvisor to use klog
• vendor all the repos above into k/k and switch k/k from glog to klog
• add verify scripts to prevent adding any new vendor dependencies that use glog

cc @thockin @tallclair @erictune @justinsb @lavalamp

/kind feature

[dims]

/sig architecture

[dims]

/assign @thockin
/assign @tallclair

[erictune]

Thank you for doing this, @dims!

Also:

• Update k8s.io/klog README.md to explain it is a permanent fork.

[liggitt]

I think we would also need to add verify scripts to prevent adding any new vendor dependencies that use glog. I'm actually very surprised we don't have more already:

$ grep -R 'glog"' vendor | egrep -v 'k8s.io|cadvisor'
vendor/github.com/golang/glog/BUILD:    importpath = "github.com/golang/glog",
vendor/github.com/kubernetes/repo-infra/kazel/kazel.go:	"github.com/golang/glog"

[dims]

+1 @erictune @liggitt updating task list above

[deads2k]

I think we would also need to add verify scripts to prevent adding any new vendor dependencies that use glog. I'm actually very surprised we don't have more already:

I think that's because this project uses godep, not something like glide which pulls in entire trees. github.com/coreos/etcd vendors github.com/grpc-ecosystem/grpc-gateway which vendors glog.

[liggitt]

we would also need to add verify scripts to prevent adding any new vendor dependencies that use glog

given the prevalence of glog usage in the go ecosystem, we also have to consider the impact of k8s.io/* components using a logging library that cannot be built into a binary that also includes glog. If a downstream consumer imports k8s.io/apimachinery or k8s.io/client-go (and therefore "klog"), and also has another dependency that uses glog, this change will break them without much recourse.

[deads2k]

Based on the discussion in SIG-Arch on Oct 25 and previous experiment in #69333, we should start by forking glog, cleanup the code to suit our use cases and switch over to it. Also see issue #61006

@dims I've had a look at your fork. Is there a list of specific objectives beyond flags and output? I think I'd be looking for something more pluggable overall if we commit to this pain.

[dims]

@liggitt to allow klog and glog to co-exist

• We have to drop the flags registration from "init" and require an explicit Init for klog
• end users can use klog's setOutput and redirect the logs from klog to glog