Skip to content

Conversation

@rosti
Copy link
Contributor

@rosti rosti commented Aug 23, 2018

What this PR does / why we need it:

This change splits out discovery fields from JoinConfiguration by performing
the following changes:

  • Introduce a BootstrapTokenDiscovery structure, that houses configuration
    options needed for bootstrap token based discovery.

  • Introduce a FileDiscovery structure, that houses configuration options
    (currently only a single option) needed for KubeConfig based discovery.

  • Introduce a Discovery structure, that houses common options (such as
    discovery timeout and TLS bootstrap token) as well as pointer to an instance
    of either BootstrapTokenDiscovery or FileDiscovery structures.

  • Replace the old discovery related JoinConfiguration members with a single
    Discovery member.

This change is required in order to cleanup the code of unnecessary logic and
make the serialized JoinConfiguration more structured (and therefore, more
intuitive).

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
refs kubernetes/kubeadm#911, refs kubernetes/kubeadm#963

Special notes for your reviewer:

This is another one of those big and somewhat hard to review PRs, that are the stepping stones in the path to v1beta1.

/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/kind api-change
/kind enhancement
/assign @luxas
/assign @timothysc
/assign @fabriziopandini

Release note:

kubeadm: JoinConfiguration now houses the discovery options in a nested Discovery structure, which in turn has a couple of other nested structures to house more specific options (BootstrapTokenDiscovery and FileDiscovery)

@k8s-ci-robot k8s-ci-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Aug 23, 2018
@k8s-ci-robot k8s-ci-robot added sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. area/kubeadm size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 23, 2018
Copy link
Member

@dixudx dixudx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For current v1alpha3, I'd prefer not to update the json structure. Use inline instead.

We could update that in next coming v1beta1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default will be nil.
Remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing newline?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break old configurations.

For coming v1beta1, we cound use a new section like this.

But for current v1alpha3, shall we use below instead in types.go,

Discovery Discovery `json:",inline"`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it won't, since v1alpha3 is also unreleased and is massively different than v1alpha2 of 1.11.
I am also not a fan of inlining it, because that way the context of the options in Discovery is gone.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto for those following yaml files.

Better not change the struction of current released v1alpha3. We could do this in coming v1beta1 instead.

@rosti
Copy link
Contributor Author

rosti commented Aug 23, 2018

For current v1alpha3, I'd prefer not to update the json structure. Use inline instead.

We could update that in next coming v1beta1.

This looks like a double work for me and I am willing to actually hold of this PR for v1beta1 if we are going to split it into user and back facing interface changes.
I am not a big fan of inlining the Discovery structure either - it gives us more context that way and makes the config file more structured.
The fact is that this change is literally tiny compared to the rest if the changes we have done in v1alpha3. I don't believe that a user facing interface change here is going to break anyone, since v1alpha3 is unreleased.

@rosti rosti force-pushed the join-discovery-split branch from 7160887 to 15a5136 Compare August 23, 2018 15:19
Copy link
Contributor

@timothysc timothysc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/hold

please coordinate this with @fabriziopandini there are overlapping issues right now.

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Aug 24, 2018
@rosti rosti force-pushed the join-discovery-split branch from 15a5136 to 46777a2 Compare August 27, 2018 10:47
@k8s-ci-robot k8s-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Aug 27, 2018
@rosti rosti force-pushed the join-discovery-split branch from 46777a2 to 7287c86 Compare September 3, 2018 15:03
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 3, 2018
@timothysc timothysc added this to the 1.13 milestone Sep 5, 2018
@timothysc timothysc removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 5, 2018
@liggitt liggitt modified the milestones: 1.13, v1.13 Sep 5, 2018
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 28, 2018
@rosti rosti force-pushed the join-discovery-split branch from 7287c86 to 99aa771 Compare October 8, 2018 14:08
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 8, 2018
@rosti
Copy link
Contributor Author

rosti commented Oct 8, 2018

Rebased the PR on v1beta1

@fabriziopandini @timothysc PTAL

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 9, 2018
@timothysc
Copy link
Contributor

@rosti bot says it still needs a rebase.
I'd like to chat about config changes tomorrow during office hours too.

@rosti rosti force-pushed the join-discovery-split branch from 99aa771 to 58754a6 Compare October 10, 2018 10:41
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 10, 2018
Copy link
Contributor

@timothysc timothysc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that you and @fabriziopandini have been working on this one I'll defer to him on lgtm

/approve
/assign @fabriziopandini

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 11, 2018
Copy link
Member

@fabriziopandini fabriziopandini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rosti thank you for this PR and +100 for keeping this going across two cycles!

Overall this PR looks fine, but the things that confused a little bit me is the move from tree token fields (discoveryToken, tlsBootstrapToken and token to override the former two) to two token fields. Some other minors inline

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wandering if it makes more sense to have two TLS bootstrap tokens, one inside BootstrapToken and one inside File.
WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok according to original Lucas design

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fully convinced by calling this path, but I don't have better suggestion ATM...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about KubeConfigFile? Yet it sounds kind of the same to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave as it is ATM

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not wrong we are missing DiscoveryToken (unless it is intentional to conflate Token and DiscoveryToken)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok according to original Lucas design

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I'm not wrong out.token is missing...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok according to original Lucas design/the semantic of --token acting as a proxy for TLSBootstrapToken/DiscoveryToken

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DiscoveryToken is missing also here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok according to original Lucas design

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wandering if we should make this string instead of accepting array of string and throwing an error in validation if more than one string is passed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make this string; we are not accepting more than one value ATM and there is no plan for supporting >1 API Endpoints as far as I know

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will come in as a followup PR as the change is not trivial (currently there is a lot of code in kubeadm, that looks upon this as a []string and doing correct handling of multiple API Servers).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be ValidateDiscoveryFile?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename to ValidateDiscoveryFile

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is out of the scope of this PR, but it would be great to rename also ValidateJoinDiscoveryTokenAPIServer into ValidateDiscoveryTokenAPIServer

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kindly rename ValidateJoinDiscoveryTokenAPIServer into ValidateDiscoveryTokenAPIServerfor consistency

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to understand why you are creating separated object instead of working on cfg, but I'm wondering if we can do the the other way around: use cfg and then clean up cfg.Discovery.File or cfg.Discovery.BootstrapToken if corresponding flags/args are not set

Copy link
Member

@fabriziopandini fabriziopandini Oct 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of this solution but we can leave with it ATM

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little bit confusing.
In the config we now there is BootstrapToken.Token and TLSBootstrapToken but not Token
here there is Token, TLSBootstrapToken but not discovery-token anymore

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the flag documentation explaining the semantics of this flag

@rosti
Copy link
Contributor Author

rosti commented Oct 12, 2018

@fabriziopandini the change is along the lines of the original proposal by Lucas, which I find the most sensible solution here.
The TLSBootstrapToken is moved to the common Discovery struct and is therefore shared by both discovery methods. The DiscoveryToken field is replaced by BootstrapToken.Token. The Token field, whose purpose in v1alpha3 was to supply a common value to use for TLSBootstrapToken and DiscoveryToken, when no value was supplied for some of them, was removed. You can still specify the --token switch on command line to supply a single value to use for both TLSBootstrapToken and DiscoveryToken. Also, v1alpha3 to internal config is making sure to do the correct conversion too.

P.S.: On second though, I got the semantics for --token a bit different than what it used to be, so I'll change fix them in a bit. They should not be overwritten by --token if they are not empty.

@rosti rosti force-pushed the join-discovery-split branch from 58754a6 to 3ecb446 Compare October 12, 2018 11:28
@rosti
Copy link
Contributor Author

rosti commented Oct 12, 2018

Fixed the --token flag semantics (of kubeadm join).

Copy link
Member

@fabriziopandini fabriziopandini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rosti
/approve
Please fix minors still pending and then ready for lgtm

After your explanation I added a note on all my previous comments that does not apply anymore, and make it clear where IMO you should fix minors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make this string; we are not accepting more than one value ATM and there is no plan for supporting >1 API Endpoints as far as I know

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename to ValidateDiscoveryBootstrapToken

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should go away when APIServerEndpoints changes from []string to string

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kindly rename ValidateJoinDiscoveryTokenAPIServer into ValidateDiscoveryTokenAPIServerfor consistency

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename to ValidateDiscoveryFile

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the flag documentation explaining the semantics of this flag

@fabriziopandini
Copy link
Member

/approve
/lgtm

/test pull-kubernetes-e2e-gce

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2018
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini, rosti, timothysc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rosti
Copy link
Contributor Author

rosti commented Oct 16, 2018

A few minor details to address in a couple of hours and this will be ready to go.

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 16, 2018
@rosti rosti force-pushed the join-discovery-split branch from f41d131 to 80971c9 Compare October 16, 2018 12:21
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2018
This change splits out discovery fields from JoinConfiguration by performing
the following changes:

- Introduce a BootstrapTokenDiscovery structure, that houses configuration
  options needed for bootstrap token based discovery.

- Introduce a FileDiscovery structure, that houses configuration options
  (currently only a single option) needed for KubeConfig based discovery.

- Introduce a Discovery structure, that houses common options (such as
  discovery timeout and TLS bootstrap token) as well as pointer to an instance
  of either BootstrapTokenDiscovery or FileDiscovery structures.

- Replace the old discovery related JoinConfiguration members with a single
  Discovery member.

This change is required in order to cleanup the code of unnecessary logic and
make the serialized JoinConfiguration more structured (and therefore, more
intuitive).

Signed-off-by: Rostislav M. Georgiev <[email protected]>
@rosti rosti force-pushed the join-discovery-split branch from 80971c9 to 576b8d3 Compare October 16, 2018 12:25
@rosti
Copy link
Contributor Author

rosti commented Oct 16, 2018

@fabriziopandini should be ready now for re-lgtm.

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 16, 2018
@fabriziopandini
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 16, 2018
@fabriziopandini
Copy link
Member

/test pull-kubernetes-kubemark-e2e-gce-big

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

1 similar comment
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

@k8s-ci-robot k8s-ci-robot merged commit 1e4ad04 into kubernetes:master Oct 17, 2018
@rosti rosti deleted the join-discovery-split branch November 22, 2018 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. area/kubeadm cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants