capnslog: deprecation notice

[tmrts]

The point of this issue is to have a discussion about moving on from capnslog to a better alternative Logrus, which is a well developed structured & pluggable logging library.

cc @philips

[philips]

We would need to fixup clair, etcd, and go-oidc.

https://godoc.org/github.com/coreos/pkg/capnslog?importers

cc @xiang90 @Quentin-M @ericchiang for their opinions.

[ericchiang]

Should be easy for go-oidc. Not particularly picky about which logging package we use.

[tmrts]

Also we should create a wrapper interface around Logrus and use that for our projects,
which would make it easy to replace Logrus and add more features to it.

As long as we don't use reflection in the wrapper, there should be no resource overhead.

Maybe with the pkg name "clog" for CoreOS Log

[Quentin-M]

@jsqware and I already discussed about replacing capnslog by logrus very recently. The only con was that capnslog is the one that every CoreOS project use.

[chancez]

@tmrts Would one of these interfaces work?

https://github.com/Sirupsen/logrus/blob/master/logrus.go#L97-L143

[xiang90]

For etcd, people might want to control the pkg level logging when they embed etcd server into their own projects. Is this something easy to do in logrus?

[tmrts]

@chancez That is an idiomatic interface. It would be fine.

But, I'd suggest going one step forward, consider the following example:

m, err := p.FetchMetadata()
if err != nil {
    log.Fatal("Failed to fetch meta-data from pod",
        log.Fields{
            Event: "k8s.Pod.FetchMetadata",
            Error: err,
        },
        log.Details{
            "pod": p,
        },
    )
}

Advantage would be consistent log messages and they would provide actionable & meaningful information. Developers wouldn't be thinking how to format the messages and it wouldn't resemble a stack dump after a crash to bug hunters.

The underlying logging library would be Logrus in this case, but it can be the stdlib logging library just as well. And the log.Details would be discarded if log.Level wasn't Debug.

Also we should name it something short and not advise people to rename this package to log it causes problems to goimports, etc. Something like clog, coslog, corelog would be good, or a better suggestion

[purpleidea]

For etcd, people might want to control the pkg level logging when they embed etcd server into their own projects. Is this something easy to do in logrus?

Above @xiang90 makes an excellent point. This is what we have to do in mgmt to avoid log pains due to capnslog:

https://github.com/purpleidea/mgmt/blob/master/lib/main.go#L186

I like the suggestion of using an internal (to etcd) interface to control logs, and whether that uses logrus or logfoo or whatever is hidden to the user embedding etcd.

[jonboulle]

I think we reached consensus a while ago on removing capnslog but just haven't allocated any time to do the migration work involved...

…

On 15 March 2017 at 09:52, James ***@***.***> wrote: For etcd, people might want to control the pkg level logging when they embed etcd server into their own projects. Is this something easy to do in logrus? Above @xiang90 <https://github.com/xiang90> makes an excellent point. This is what we have to do in mgmt to avoid log pains due to capnslog: https://github.com/purpleidea/mgmt/blob/master/lib/main.go#L186 I like the suggestion of using an internal (to etcd) interface to control logs, and whether that uses logrus or logfoo or whatever is hidden to the user embedding etcd. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACewNxXp9ScOxligyqtKPCU4hJF-Gnt7ks5rl6bXgaJpZM4IVJg4> .