Add proposal for kubeadm feature flags

[bogdando]

What this PR does / why we need it: See proposal in the gdoc https://goo.gl/K90i3N (duplicated here as well)

Release note:

Related #35133
This one must be amended to the original proposal, kubernetes/enhancements#11,
once its design accepted.

Signed-off-by: Bogdan Dobrelya [email protected]

---

This change is

[k8s-ci-robot]

Can a kubernetes member verify that this patch is reasonable to test? If so, please reply with "@k8s-bot ok to test" on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands will still work. Regular contributors should join the org to skip this step.

If you have questions or suggestions related to this bot's behavior, please file an issue against the kubernetes/test-infra repository.

[errordeveloper]

cc @kubernetes/sig-cluster-lifecycle

[luxas]

@kubernetes/sig-cluster-lifecycle Any others than me that thinks that this could just be a gdoc instead of a proposal in the main repo?

We already have the original kubeadm proposal, and
a) this PR should modify that proposal
b) this should be just a gdoc
c) we can discuss this design in an issue

WDYT?
This doesn't seem big enough for a full proposal IMO, but on the other hand, I don't know if we have any formalized process for what should and shouldn't be written as a proposal.

[brendandburns]

I think that this lacking some stuff as is (and I think I second amending the existing proposal, rather than creating an alternate one)

I think that I'd like to see a crisp proposal for what is to be added. There is a general overview of the goals, and some concrete user examples, but there is no specific specification of the complete new commands, syntax, etc. I'd like to see more detail so that we actually know what is being proposed, rather than just the problem statement.

Thanks!

[brendandburns]

nit kubeadm here and elsewhere.

[brendandburns]

kubeadm

[brendandburns]

This sentence is awkward, rephrase?

[bogdando]

@luxas how could I amend the PR to modify the original kubeadm proposal? In gerrit it is as simple as uploading a new revision, but I have no idea how to do the same with open github PRs :(

[luxas]

@bogdando What about a google doc first? I think that would be best.
That's how we started the other sig-cluster-lifecycle proposals as well, and it's best if everyone can easily edit that's in the group initially.

If you want to update your pr, just push or force-push to your branch

[bogdando]

@luxas Sorry for confusing words, I meant the original PR:

We already have the original kubeadm proposal, and
a) this PR should modify that proposal

how to update it with this change?
As for google doc, I think the reviewable extension gives a lots more than gdocs for a generic review process. See https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/35689 . I found that more convinient than sharing some google docs to some ppl (which ones?) in my private space, or Mirantis gdoc space? That becomes too much complicated, sorry.

[bogdando]

@luxas here is the gdoc https://goo.gl/K90i3N

[luxas]

I think it should be possible to restrict the editing to folks in the [email protected] google group

@lukemarsden knows how I guess

[luxas]

I agree with Brendan, this isn't really a proposal and shouldn't be a doc on its own.
Right now we only have the problem statement, which is documented in a lot of other places and a lot of flags that can be appended to init and join (which can't easily be implemented either)

Please, can you just file an issue in kubernetes/kubernetes where you're proposing what you'd like to see or make a gdoc like everyone else does?

This is also clearly an unmaintainable design which we can't/won't implement IMO.
We're going towards a config-file-based configuration approach, so flags to init and join will be kept minimal
And just think about what if you like to run kubeadm init --certificates and specify an argument to the certificates process? We would end up with 20s of flags that conflict with each other and the opinionated setup process is gone.

Instead we should make a new, advanced command called kubeadm manual or something like that and subcommands that does the specific tasks kubeadm should do. This will require quite a lot of refactoring work indeed, but it's clean and worth it.

We should identify later which phases there are in the kubeadm setup, and propose a comprehensive kubeadm manual design, but not in this proposal document/PR.

[bogdando]

@luxas runtime options allow to opt-in required features only and invoke kubeadm multiple times just simple as changing opt-in flags one want to call (wrapped in docker run perhaps) and make it stupid simple. While manipulating with config file is tedious and bad design, specifically for feature flags. I agree on proposed steps and kubeadm manual and refactoring. But the primary task is removing a blocker for external CM tools integration, which is inability to invoke kubeadm for a specific action only. Once that blocker removed, we shall proceed to further design.

This is about KISS implementation for the blocker removal, with minimum of required changes and nothing more complex.

[bogdando]

@luxas : @brendandburns

I agree with Brendan, this isn't really a proposal and shouldn't be a doc on its own.

Folks, let's followup please. I understood the Brendan's comment as a request for more details on implementation, thus this directly conflicts to the cited statement. And at least this must be amended to the original spec kubernetes/enhancements#11, before closed.

[brendandburns]

@bogdando the intent of my comment was that before the proposal can be considered, there has to be sufficient detail to understand what it is proposing before we can even evaluate the proposal.

I think I'm with @luxas here that I think the right way forward is to add more detail to the existing kubernetes/enhancements#11, and then re-factor this proposal to describe how it solves those issues.

Once that's done, I think that we'll be in good shape to understand if the proposal should be accepted or not.

Thanks!
(and sorry, I realize this is kind of bureaucratic, but I think for things like this where there can really only be one kubeadm and much of the community will (hopefully) use it, we need to be crisp and get a clear understanding of what we are building before we commit to building it)

[bgrant0607]

@bogdando Could you please describe scenarios for how you imagine these options to be used? Do you need to perform other operations in between the steps? Retry steps? Reorder steps?

Small numbers of flags and seem targeted at manual, interactive usage. Large numbers of flags aren't really easy to deal with for any use case. That approach basically requires a configuration management tool to translate from options specified some other way. In general, we find that configuration is more composable and therefore more amenable to higher-level automation.

Subcommands to invoke individual steps that read a subset of the configuration could potentially work, but this may expose too many implementation details. I assume it would be a problem if steps were added or removed.

[bogdando]

@bgrant0607 I described example workflow and use cases and goals in the gdoc https://goo.gl/K90i3N

[bogdando]

Updated the spec and gdoc with that @jbeda proposes in #35907 (comment).
@luxas what should be next steps to get that merged into the main kubeadm spec and changes to the spec being maintained there since then?

[k8s-github-robot]

Adding label:do-not-merge because PR changes docs prohibited to auto merge
See http://kubernetes.io/editdocs/ for information about editing docs

[luxas]

Proposals should now target the community repo, so closing this one.

Also, here's my GDOC that includes the refactoring of the binary which will lead to separately invokable commands (which will solve this issue when done): https://docs.google.com/document/d/1v4k7eN-eetHbbpTAG7WuioRAMsK_FVGi1yC3VIn4Inw