Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add building without in tree providers #1180

Merged
merged 1 commit into from
Aug 6, 2019

Conversation

BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Jul 29, 2019

KEP for #1179

Previously discussed in SIG Cloud Provider, and with some SIG Release members. This is Nominally SIG Cloud Provider but the alternate build mode should also interest and include SIG Release.

@k8s-ci-robot
Copy link
Contributor

Welcome @BenTheElder!

It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/enhancements has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. labels Jul 29, 2019
@BenTheElder
Copy link
Member Author

/assign @cheftako @andrewsykim @justaugustus

@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 29, 2019
@BenTheElder
Copy link
Member Author

pending #1181 to fix update-toc.sh

@BenTheElder BenTheElder force-pushed the keptocracy branch 4 times, most recently from ac43874 to cd48d07 Compare July 29, 2019 22:13
- "@cheftako"
- "@andrewsykim"
- "@stephenaugustus"
approvers:
Copy link
Member

Choose a reason for hiding this comment

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

Seems like we should have at least one approver from cloud-provider and one approver from each of testing and release. We should also make sure they are not from the same company.

Copy link
Member

Choose a reason for hiding this comment

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

I can be an approver on behalf of sig-testing if it'll help

Copy link
Member Author

Choose a reason for hiding this comment

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

happy to add / remove as necessary, added the current reviewers to approvers and @spiffxp to both which now cover:

@andrewsykim - (Cloud Provider, VMware)
@cheftako - (Cloud Provider, Google)
@spiffxp - (Testing, Google)
@justaugustus - (Release, VMWare)

@BenTheElder BenTheElder force-pushed the keptocracy branch 2 times, most recently from 38dcf52 to f27be4a Compare July 29, 2019 23:16
@davidz627
Copy link
Contributor

/cc @davidz627 @ddebroy

@BenTheElder BenTheElder force-pushed the keptocracy branch 2 times, most recently from 2a4de29 to ff90cac Compare July 31, 2019 22:23
@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 1, 2019
Copy link
Member

@cheftako cheftako left a comment

Choose a reason for hiding this comment

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

/lgtm

Copy link
Member

@spiffxp spiffxp left a comment

Choose a reason for hiding this comment

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

Thanks for putting this together

In order to make this work the following additional changes are made:

- Packages that we fully exclude (the legacy provider packages) _must_ contain
a `doc.go` file or any other file that does NOT contain any code or build
Copy link
Member

Choose a reason for hiding this comment

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

Just a note that I don't see any doc.go verbiage specified here. I'm comfortable seeing this KEP merge and having the verbiage sorted out over in the prototype PR

eg: https://github.com/kubernetes/kubernetes/pull/80353/files#diff-fe522781fb7f1bf08a17a523c264ffb6 no verbiage at the moment


## Design Details

### Test Plan
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 fine with the test plan for now. Would like to see us refine this with links to the relevant jobs/dashboards as we get them setup

Copy link
Member Author

Choose a reason for hiding this comment

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

Would like to see us refine this with links to the relevant jobs/dashboards as we get them setup

Yeah, those will be pending the initial implementation, it doesn't make much sense to write CI jobs / dashboards for a build mode that doesn't exist yet.

I also expect in the future to be supporting various groups implementing their own CI making use of this build mode (EG cloud-provider-foo repo CI), but I'm not sure that belongs here exactly other than the user stories. It remains to be seen which foos take this up.

@spiffxp
Copy link
Member

spiffxp commented Aug 1, 2019

/lgtm
as sig-testing approver

Copy link
Member

@ddebroy ddebroy left a comment

Choose a reason for hiding this comment

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

Looks good and the approach is pretty nice! Just had a couple of clarifying questions.

- A few locations in the code do not properly use the cloud provider interface
(instead, importing the cloud provider packages directly),
some of these must be updated with both a "with provider" version and a
"without provider" version broken out of the existing code. In particular this
Copy link
Member

Choose a reason for hiding this comment

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

Does this cover the moving of the ProbeVolumePlugin calls to cmd/kube-controller-manager/app/plugins_legacyproviders.go?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, the next line mentions in-tree volumes

- Changing the official Kubernetes release builds
- Building the e2e tests
- Decoupling cloud providers is a larger problem there and not necessary to test out-of-tree providers or build smaller binaries
- Mechanisms for migrating to out of tree providers
Copy link
Member

Choose a reason for hiding this comment

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

Should it be called out explicitly (besides mechanisms to migrate to out-of-tree providers) that maintaining API compatibility with existing in-tree providers (e.g. for in-tree volumes) is a non-goal in the context of this KEP and associated PRs as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe? Inherently there can't / won't be the same cloud provider and what cloud providers do exist will depend on the CCM deployed when using this. This is not new to this KEP.

For storage / in-tree volumes etc. anything broken in this build mode will eventually be broken when the in-tree cloud providers are removed and must be fixed regardless of this KEP.

The intention behind this KEP is to help surface what those things are and verify that we've fixed them as we do that. Fixing them however is out of scope.

That said, to implement it we do have to do a bare minimum of decoupling just to get a build that compiles, and that has surfaced some pending breakages already that are called out in the KEP (E.G. GCE node IPAM which we need to finish deprecating and remove).

More specific to this point I have met with @davidz627 about CSI migration testing & this KEP and we do intend to make sure that we can test CSI migration specifically, possibly not in the first implementation PR though and possibly (?) orthogonally to the KEP.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for clarifying that potential fixes for issues that arise at run-time (rather than at build-time) is out of scope.

Copy link
Member Author

Choose a reason for hiding this comment

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

Should also add -- I'm also interested in helping fix those runtime issues myself, but I don't think that belongs in the KEP 😅

@spiffxp
Copy link
Member

spiffxp commented Aug 1, 2019

pinged @andrewsykim and @justaugustus for signoff by remaining approvers listed on the KEP

### Non-Goals

- Building the out of tree providers
- Changing the official Kubernetes release builds
Copy link
Member

Choose a reason for hiding this comment

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

Are there any plans to support an "unofficial" release using this build tag? I'm assuming not in the immediate future but maybe later?

Copy link
Member Author

Choose a reason for hiding this comment

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

We'll likely need one as part of any CI using it, kube-up, kops etc. tend to rely on a release tarball being somewhere in cloud storage, we can handle this the same as the other CI based builds which are definitely not official releases but are regularly pushed to well known location(s).

We have a number of these already including bazel based quick release, make based quick release, and the cross compile build, I think it would be pretty reasonable to add a "without in tree providers" CI build.

Copy link
Member Author

Choose a reason for hiding this comment

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

So I would say yes, as a follow up to getting the build tag working we'll first want to figure out a nice way to invoke building something like a release with it, and then we'll want CI for it.

I think this is sorta covered by the test plan but maybe could be more explicit 🤔

@andrewsykim
Copy link
Member

/approve
/hold

Leaving hold cancel to @BenTheElder and @justaugustus

@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. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Aug 1, 2019
@justaugustus
Copy link
Member

Looks great, @BenTheElder!
/lgtm
/approve
/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 Aug 6, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, BenTheElder, cheftako, justaugustus, spiffxp

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

The pull request process is described here

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

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. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants