/sig cloud-provider

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 ?

@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.

so where do the cloud providers code go once removed ?

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

ok thanks, the info is being propagated

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

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

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

@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!

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

@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?

@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?

@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

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.

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! :)

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/

/milestone v1.12

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

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

[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

/priority critical-urgent

/test pull-kubernetes-e2e-kops-aws

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

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.

@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.

@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.

@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.

@sebgoa Any update on this?

@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...

@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 ?

@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.

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

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

@rhtyd thats great news!

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 ?

@rhtyd
Good !!