pkg/assets/create: Replace Verbose and StdErr with Logger by wking · Pull Request #225 · openshift/library-go

wking · 2019-02-05T18:07:15Z

To allow consumers to plug in their preferred logger instead of requring an output stream. I'm using go-log/log as an unopinionated interface, which callers can feed with the stdlib's log package, logrus, etc. depending on their logging preferences.

CC @mfojtik, @sttts

To allow consumers to plug in their preferred logger instead of requring an output stream. I'm using go-log/log [1] as an unopinionated interface, which callers can feed with the stdlib's log package, logrus, etc. depending on their logging preferences. [1]: https://github.com/go-log/log

Generated with: $ alpha-build-machinery/scripts/update-deps.sh Also bring in stretchr/testify/assert for convenient test assertion. The the bumps to the other libraries are because Glide.yaml is floating them at master or their indirect dependencies.

openshift-merge-robot · 2019-02-06T06:28:22Z

/retest

mfojtik · 2019-02-06T09:16:22Z

We should not import new package here, instead we can create the interface here and plug whatever we need there (the interfaces are exchangeable). I would just copy https://github.com/go-log/log/blob/master/log.go#L5 at the top of the create.go

mfojtik · 2019-02-06T09:18:13Z


-	if options.Verbose && options.StdErr == nil {
-		options.StdErr = os.Stderr
+	if options.Logger == nil {


If the options.Logger is not set, just don't log anything or create some dummy implementation of Logger interface?

If the options.Logger is not set, just don't log anything or create some dummy implementation of Logger interface?

The default I'm plugging in in this block is a no-op logger unless the user set that package-level global.

tnozicka · 2019-02-06T09:54:48Z

/hold

The whole org uses glog for very clear reason, because the whole k8s apimachinery and client-go is tightly coupled to it. Using more then 1 logger is a lost of time and will not work given the hardcoded glog in k8s. You just don't use 2 loggers in 1 project.

tnozicka · 2019-02-06T09:55:00Z

/cc @deads2k

sttts · 2019-02-06T10:09:17Z

Decoupling the code from glog is fine, but not by pulling in another package. Let's just abstract with a local interface and every consumer can plug a wrapper in for his/her favourite logger.

tnozicka · 2019-02-06T10:52:19Z

Making more loggers configurable is work that could have been better spent on important things, same goes for reviews.

In the end the same statement applies for logging in the end component, if it doesn't use glog.

(note: I personally don't like glog at all, but I understand the necessity of using it implied by being hardcoded in k8s.)

wking · 2019-02-06T11:33:58Z

The whole org uses glog for very clear reason...

The installer inherited logrus. I don't see it consuming this code directly, but I also don't see a need for opinionated logging in libraries. However, I can reroll to take glog (or klog?) types if folks don't like the interface approach.

We should not import new package here, instead we can create the interface here and plug whatever we need there (the interfaces are exchangeable).

Why copy/paste this (and the no-op implementation), when they're already written and can be vendored? Seems easier to maintain that way, and if your vendor tooling pruned unused packages it would be about the same amount of code either way.

wking · 2019-02-06T11:39:54Z

Also, lots of Kubernetes library log handling discussion in kubernetes/kubernetes#61006, where interface-based approaches were raised but not accepted (although I'm still not clear on why not).

soltysh · 2019-02-06T11:54:57Z

The installer inherited logrus. I don't see it consuming this code directly, but I also don't see a need for opinionated logging in libraries. However, I can reroll to take glog (or klog?) types if folks don't like the interface approach.

Klog will be brought up with 1.13 kubernetes, so I wouldn't bother with that, yet.

Also, lots of Kubernetes library log handling discussion in kubernetes/kubernetes#61006, where interface-based approaches were raised but not accepted (although I'm still not clear on why not).

That's one of the reasons klog happened, it might be a road towards just that, we'll see.

deads2k · 2019-02-06T13:13:47Z

 	"time"

 	"github.com/ghodss/yaml"
+	"github.com/go-log/log"


no new logging dep. Project standard is glog and we'll switch to klog with kube.

deads2k · 2019-02-06T13:14:50Z

-				if options.Verbose {
-					fmt.Fprintf(options.StdErr, "[#%d] failed to fetch discovery: %s\n", retryCount, err)
-				}
+				options.Logger.Logf("[#%d] failed to fetch discovery: %s", retryCount, err)


project standard upstream and downstream is fmt.printf for CLI and glog for everything else. The previous code is in keeping.

project standard upstream and downstream is fmt.printf for CLI and glog for everything else. The previous code is in keeping.

But this is library code, so I'd expect glog over fmt, right?

@wking depends on the caller of this code. So far it is cluster-bootstrap which is a command we run during the bootstrap (so it is CLI ;-). I'm fine switching this to glog, was trying to avoid importing glog because I know that some components/cli have problem with parsing glog flags (so wanted to avoid that if not necessary).

depends on the caller of this code. So far it is cluster-bootstrap which is a command we run during the bootstrap (so it is CLI ;-).

I don't think code in library-go should have API choices hinge on "we know all of our consumers, and they're not libraries themselves". Is there a reason that approach is not as brittle as it seems?

I'm fine switching this to glog, was trying to avoid importing glog because I know that some components/cli have problem with parsing glog flags (so wanted to avoid that if not necessary).

Like openshift/installer#1181. This is exactly why I prefer logging interfaces, but it sounds like that's a no-go?

deads2k · 2019-02-06T13:14:58Z

/hold

wking · 2019-02-07T00:12:15Z

Hrm. I went to reroll this to use glog as requested by @tnozicka here @deads2k here. But I'm stuck with collecting the logs for unit tests. Should I drop those tests? Should I have init code set -log_dir and collect the test logs there? Should I add an interface after all so the test suite can plug in a capture implementation (but with copies to local code, and not the vendored capture implementation I'm currently using as of 673e3d3?)?

openshift-ci-robot · 2019-02-09T07:35:50Z

@wking: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

openshift-ci-robot · 2019-12-18T11:15:39Z

@wking: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/prow/verify-deps	`673e3d3`	link	`/test verify-deps`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

openshift-bot · 2020-09-24T05:18:27Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot · 2020-10-25T01:12:31Z

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

openshift-bot · 2020-11-24T03:02:41Z

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci-robot · 2020-11-24T03:02:55Z

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

wking added 2 commits February 5, 2019 10:00

vendor: Bump to include go-log/log

673e3d3

Generated with: $ alpha-build-machinery/scripts/update-deps.sh Also bring in stretchr/testify/assert for convenient test assertion. The the bumps to the other libraries are because Glide.yaml is floating them at master or their indirect dependencies.

openshift-ci-robot requested review from abhinavdahiya and deads2k February 5, 2019 18:07

openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Feb 5, 2019

This was referenced Feb 5, 2019

assets: add creater based on dynamic client #220

Merged

Use library-go assets create to create bootstrap manifests openshift/cluster-bootstrap#14

Merged

mfojtik reviewed Feb 6, 2019

View reviewed changes

openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 6, 2019

deads2k reviewed Feb 6, 2019

View reviewed changes

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 9, 2019

openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 24, 2020

openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 25, 2020

openshift-ci-robot closed this Nov 24, 2020

Conversation

wking commented Feb 5, 2019

Uh oh!

openshift-merge-robot commented Feb 6, 2019

Uh oh!

mfojtik commented Feb 6, 2019

Uh oh!

mfojtik Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

wking Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

tnozicka commented Feb 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnozicka commented Feb 6, 2019

Uh oh!

sttts commented Feb 6, 2019

Uh oh!

tnozicka commented Feb 6, 2019

Uh oh!

wking commented Feb 6, 2019

Uh oh!

wking commented Feb 6, 2019

Uh oh!

soltysh commented Feb 6, 2019

Uh oh!

deads2k Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

deads2k Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

wking Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

mfojtik Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

wking Feb 6, 2019

Choose a reason for hiding this comment

Uh oh!

deads2k commented Feb 6, 2019

Uh oh!

wking commented Feb 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 9, 2019

Uh oh!

openshift-ci-robot commented Dec 18, 2019

Uh oh!

openshift-bot commented Sep 24, 2020

Uh oh!

openshift-bot commented Oct 25, 2020

Uh oh!

openshift-bot commented Nov 24, 2020

Uh oh!

openshift-ci-robot commented Nov 24, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

tnozicka commented Feb 6, 2019 •

edited

Loading

wking commented Feb 7, 2019 •

edited

Loading