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

Deprecate cloudstack and ovirt controller projects #68199

Merged

Conversation

dims
Copy link
Member

@dims dims commented Sep 3, 2018

Change-Id: Icca9142940269ad1cd28f1f3491684a1bc626c55

What this PR does / why we need it:
Do we have folks invested in these providers trying to work on the external controllers for these providers? Is there a future for these providers? If not can we deprecate and eventually remove them?

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:
cc @ngtuna @sebgoa @svanharmelen (for cloudstack)
cc @simon3z

Release note:

Deprecate cloudstack and ovirt controllers

Change-Id: Icca9142940269ad1cd28f1f3491684a1bc626c55
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Sep 3, 2018
@dims
Copy link
Member Author

dims commented Sep 3, 2018

/sig cloud-provider

@sebgoa
Copy link
Contributor

sebgoa commented Sep 4, 2018

I will ping the cloudstack developer list.

In general though, it is not because you don't see activity that something is not used.

I do have one quesstion, all the cloud providers were supposed to be moved out of the main repo. What happened to that effort ?

@dims
Copy link
Member Author

dims commented Sep 4, 2018

@sebgoa this is part of that effort, we need folks to pick up work for making these external.

fyi, the first one to be removed from k/k will be the openstack provider, a WIP is in #67782 and will be merged when v1.13 opens up.

@sebgoa
Copy link
Contributor

sebgoa commented Sep 4, 2018

so where do the cloud providers code go once removed ?

@dims
Copy link
Member Author

dims commented Sep 4, 2018

Short answer:
https://github.com/kubernetes?utf8=%E2%9C%93&q=cloud-provider&type=&language=

Longer answer:
Please ask whoever is going to be doing this to join the slack channel #sig-cloud-provider and review the keps and get active in the effort
https://github.com/kubernetes/community/tree/master/keps/sig-cloud-provider

@sebgoa
Copy link
Contributor

sebgoa commented Sep 4, 2018

ok thanks, the info is being propagated

@sandrobonazzola
Copy link

For oVirt side I'm propagating the info, please hold on.

@dims
Copy link
Member Author

dims commented Sep 4, 2018

cc @kubernetes/sig-cloud-provider-misc @andrewsykim

@rohityadavcloud
Copy link
Member

Hi @dims, some CloudStack users are using the k8s CloudStack provider for external LB (https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer) service and to add/remove LB rules for a network of a (container) cluster. We may want to keep that in for such users and also in case in future we may want to add support for more features. We also have an ongoing k8s integration plugin which may need further support it in future: https://github.com/shapeblue/ccs

@dims
Copy link
Member Author

dims commented Sep 7, 2018

@rhtyd the mandate is to clean up k/k repository of all cloud providers. So unless there is a owner to move the code out into external repositories, the code will be deprecated and then removed. So please tell folks that they need to show up and help move stuff out so things can be still used. This is for all cloud providers!

@rohityadavcloud
Copy link
Member

Thanks @dims. @ustcweizhou can you take a lead on this? /cc other ACS contributors - @wido @DaanHoogland @mike-tutkowski @khos2ow @swill @rafaelweingartner @PaulAngus @marcaurele

@rafaelweingartner
Copy link

@rhtyd it seems that we will need a new repository at Apache org to host this kuerbenets project. We will need to ask infra for that, right?

@rohityadavcloud
Copy link
Member

@rafaelweingartner I think it's best to keep the provider under k8s, like https://github.com/kubernetes/cloud-provider-openstack ? @dims can projects host/maintain providers outside of k8s github organisation, and can it have any impact wrt releases and integration?

@dims
Copy link
Member Author

dims commented Sep 7, 2018

@rhtyd Totally, the repos can be anywhere! that's how we are going about it. Not all providers will move into kubernetes org. they should live where folks related to it congregate and take care of it. So +1 to do the cloudstack one in apache.org

@rafaelweingartner
Copy link

I think I misunderstood then. I thought that this movement of code to specific repositories was a shift to move the "burden" on the management of such drivers/plugins into the cloud platform that want to integrate with Kubernetes.

Anyways, I think we (ACS community) can work together to maintain and develop this integration.

@rhtyd do you think it is better to maintain the code under Kubernetes org?Or, maybe a shift to Apache org where we (PMCs and committers) will have a more direct control over the code?

At first sight, it seems that if we keep the code under Kubernetes org, there will be a smoother integration process with the life-cycle of Kuerbenetes release process.

@andrewsykim
Copy link
Member

andrewsykim commented Sep 7, 2018

We as a community are trying to uphold certain technical standards for cloud providers in the kubernetes (or kubernetes-sigs) org. You can see them here https://github.com/kubernetes/community/blob/master/keps/sig-cloud-provider/providers/0004-cloud-provider-template.md#prerequisites. For in-tree providers we have been making some exceptions for smoother transition, however, if those requirements can't be meant in the near future, as dims mentioned, I would strongly recommend just creating the new repository in your own org as providers without clear ownership will be deprecated going forward.

Hope that helps! :)

@dims
Copy link
Member Author

dims commented Sep 7, 2018

Also please note that this PR is just about deprecation, not actual removal of code. Deprecation policy is here:
https://kubernetes.io/docs/reference/using-api/deprecation-policy/

@dims dims changed the title [WIP] Deprecate cloudstack and ovirt controller projects Deprecate cloudstack and ovirt controller projects Sep 7, 2018
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 7, 2018
@dims
Copy link
Member Author

dims commented Sep 7, 2018

/milestone v1.12

@k8s-ci-robot k8s-ci-robot added this to the v1.12 milestone Sep 7, 2018
@dims
Copy link
Member Author

dims commented Sep 7, 2018

@andrewsykim since everyone that needed to be notified have been notified and discussions have begun. Can we please move this forward for 1.12?

@andrewsykim
Copy link
Member

Sounds good to me. Given there are no clear owners to either provider (i.e no one in OWNERS file) and this is only for deprecation warning I think it's safe to move forward on this. Thanks @dims!

/lgtm

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

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, dims

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

@dims
Copy link
Member Author

dims commented Sep 8, 2018

/priority critical-urgent

@k8s-ci-robot k8s-ci-robot added the priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. label Sep 8, 2018
@dims
Copy link
Member Author

dims commented Sep 8, 2018

/test pull-kubernetes-e2e-kops-aws

@k8s-github-robot
Copy link

/test all [submit-queue is verifying that this PR is safe to merge]

@k8s-github-robot
Copy link

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

@k8s-github-robot k8s-github-robot merged commit 8d1127c into kubernetes:master Sep 9, 2018
@sebgoa
Copy link
Contributor

sebgoa commented Sep 9, 2018

@dims I am bit surprised by this merge. you pinged us 6 days ago, we are actively trying to figure out the best path forward and identify who relies on this bit of code.

and then "boom" merged, this is not very community engaging. If you wanted us to engage in the sig-cloud-provider this was definitely not the way to go about it.

@dims
Copy link
Member Author

dims commented Sep 9, 2018

@sebgoa Apologies. A bit more context, If we announce it now for 1.12, the actual code removal will be at least 3+ releases away. Hence the rush to get it in.

@hogepodge
Copy link

@sebgoa regardless of if cloudstack plans to work with sig-cloud-provider on an external provider, it's a stated goal for all in-tree providers to be removed. This is the first step, and does not remove functionality. It just warns users who depend on it that it is deprecated. We can update the string to point users in the right direction.

Personally, I want broad cross-platform activity within sig-cloud-provider, since in my opinion it only strengthens the community to have many different choices offered in a fair and consistent way. I'm very sorry that we hadn't reached out to you earlier and explained the situation and the options more clearly.

@dims
Copy link
Member Author

dims commented Oct 25, 2018

@sebgoa Any update on this?

@sebgoa
Copy link
Contributor

sebgoa commented Oct 25, 2018

@rhtyd @rafaelweingartner @svanharmelen I don't have time to do this. So you all should think about what you want to do. My understanding is that the code will be removed from the core repo.

Moving the cloud provider code out has been discussed for a while. The question is where to host that code: apache infra or ask for k8s org. The PMC should decide...

@sebgoa
Copy link
Contributor

sebgoa commented Oct 25, 2018

@dims Hi, I merely pinged folks that work on cloudstack now. I don't anymore. Is your expectation that someone should send a PR to remove the code ?

@dims
Copy link
Member Author

dims commented Oct 25, 2018

@sebgoa best case scenario would be for them to get started on their own external cloud provider. But engagement of any kind would be welcome.

@svanharmelen
Copy link

@sebgoa I’m also no longer working with/on any CloudStack related stuff (switched jobs).

@rohityadavcloud
Copy link
Member

rohityadavcloud commented Oct 27, 2018

here, @sebgoa and others someone has started a custom k8s provider (ccm) https://github.com/tsuru/custom-cloudstack-ccm

@dims
Copy link
Member Author

dims commented Oct 27, 2018

@rhtyd thats great news!

@sebgoa
Copy link
Contributor

sebgoa commented Oct 28, 2018

Let's see if we can ping these folks.

@andrestc @cezarsa looks like you are working on a cloudstak provider for k8s. Do you know that the one currently in k8s core is going to be removed ?

@ustcweizhou
Copy link

@rhtyd
Good !!

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. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet