Kubeadm: Implement different verbosity levels in kubeadm

[luxas]

From the upgrades proposal and other design discussions it is clear that it's time for kubeadm to implement a --v flag now that kubeadm implements more advanced features where more logging would be useful.

This would be a great contribution for someone that want to get their hands dirty with something...

[jnardiello]

If nobody else wants to work on this, I'll do it.

[luxas]

@jnardiello Sounds very good. We should align with what kubectl is doing.
Please go and check the verbosity features of kubectl first; how they've implemented that and then come back here and propose how to solve it before starting to code.
This to reduce the times you have to rework your PR.

cc @kubernetes/sig-cli-feature-requests
Could you comment quickly what's the best way of doing this please?

[mengqiy]

Searching glog.V\(\d\).infof in the codebase should give some information how to do it.

[jnardiello]

Thanks @mengqiy for the info, I've started walking through the code of the kubectl but will implement this in the upcoming days.

[luxas]

Moving this out of v1.8, it's not gonna make it. Instead, we'll have --dry-run as a first step (#389)

[jamiehannaford]

@jnardiello Did you make any progress on this?

[vbmade2000]

@luxas Is https://github.com/kubernetes/kubernetes/issues/25272 you are talking about ?

[luxas]

@vbmade2000 No, this is about adding _any_ kind of advanced logging solution to kubeadm, not about adding one more logging feature to kubectl.
@vbmade2000 Are you interested in contributing to this effort?

[vbmade2000]

@luxas Surely I am if @jnardiello doesn't have any issue with that. Earlier I started walking through kubeadm code but due to time constraints I couldn't do much.

[luxas]

@vbmade2000 will you join our meeting later today? That could be a great place for you to get some intro to what needs to be done here. @jnardiello doesn't seem to have time (and absolutely no worries for that!)

[vbmade2000]

@luxas I shall try but can't assure you. I think it is under SIG Cluster Lifecycle. Correct me if I am wrong. Also I believe recordings of meetings are available if I won't be able to attend.

[vbmade2000]

@luxas @mengqiy Can you provide some more detail ?

[luxas]

I think it is under SIG Cluster Lifecycle

Correct.

Also I believe recordings of meetings are available if I won't be able to attend.

True, see our meeting notes

@luxas @mengqiy Can you provide some more detail ?

Details on what? This feature request?
Basically, see how kubectl does logging, and start using something like that (or start using something kubectl will eventually switch to). As long as one can set logging levels, I'm fine.
That way we'll be able to let the user see varying amounts of information as necessary.

[vbmade2000]

Thanks @luxas

[vbmade2000]

@luxas Just to inform about my approach, I was thinking about adding a Persistent flag v to root command of kubeadm created in this here code.

[luxas]

@vbmade2000 As we do this gradually, I'd recommend starting with adding the --v flag per command that supports it. e.g. start with kubeadm init, and then implement support for extended logging for the other commands as we go.

cc @thockin @ncdc @jbeda that have been talking about doing things "the right way" on Twitter IIRC :smile:. We're starting "clean" here so should we do the fancy thing (tm) or not here?

[vbmade2000]

@luxas Ok. I'll work on that. Thanks :)

[jnardiello]

Ehi @luxas absolutely no issue here, as you pointed out I've no time :( I shall try to dedicate more time on the SIG group in the future.

@vbmade2000 I absolutely encourage you to contribute on this and join @luxas in the SIG Cluster Lifecycle. This is something I really want us to get done.

[vbmade2000]

Sure @jnardiello . I'll try to spend more time for SIG Cluster Lifecycle.

[vbmade2000]

@luxas I have been working on this since some time and I have already done lot of work on this. Is it possible to merge it in parts/phases ? Like separate merge for separate command hierarchy.

[luxas]

@vbmade2000 it sure is. I'd recommend one PR with everything, and then sending smaller PRs as you go, like I did with the upgrades PR: https://github.com/kubernetes/kubernetes/pull/48899

[vbmade2000]

@luxas Ok. Do you mean PR flow like below ?

1. Raise main PR
2. Push small change
3. Review
4. Modify if needed
5. Merge
6. Append changes
7. Follow steps 2 to 5 until all the changes are merged
8. Close PR

[luxas]

Something like this yeah:

1. Create one PR with everything needed
2. Split small, atomic part into a second PR
3. Review, modify if needed and mergee the small, second PR
4. Rebase the all-in-one-PR
5. Repeat 2 to 4 until only one thing exists in the main PR
6. Merge the main PR

[mattkelly]

@vbmade2000 I see #57661 was opened for this a while ago but there's been no activity for almost a month. Any update on the status / do you need some help on the implementation side? This feature would be super helpful so I'm interested in helping get it done if needed :).

[vbmade2000]

@mattkelly I am sorry for delay. I have been out of bandwidth since days so couldn't work much on it. I have finished much of the work so I'll look into it and create PR asap. Thanks for reminding :)

[alvarosIGZ]

@vbmade2000 any news about it?