FYI, New repo is ready! https://github.com/kubernetes/cloud-provider-openstack
We could use a lot of help. So please join us. -- Dims On Tue, Mar 13, 2018 at 1:54 PM, Chris Hoge <ch...@openstack.org> wrote: > At the PTG in Dublin, SIG-K8s started working towards migrating the > external Kubernetes OpenStack cloud provider[1] work to be an OpenStack > project. Coincident with that, an upstream patch[2] was proposed by > WG-Cloud-Provider to create upstream Kubernetes repositories for the > various cloud providers. > > I want to begin a conversation about where we want this provider code to > live and how we want to manage it. Three main options are to: > > 1) Host the provider code within the OpenStack ecosystem. The advantages > are that we can follow OpenStack community development practices, and > we have a good list of people signed up to help maintain it. We would > also have easier access to infra test resources. The downside is we pull > the code further away from the Kubernetes community, possibly making it > more difficult for end users to find and use in a way that is consistent > with other external providers. > > 2) Host the provider code within the Kubernetes ecosystem. The advantage > is that the code will be in a well-defined and well-known place, and > members of the Kubernetes community who want to participate will be able > to continue to use the community practices. We would still be able to > take advantage of infra resources, but it would require more setup to > trigger and report on jobs. > > 3) Host in OpenStack, and mirror in a Kubernetes repository. We would > need to work with the K8s team to make sure this is an acceptable option, > but would allow for a hybrid development model that could satisty the > needs of members of both communities. This would require a committment > from the K8s-SIG-OpenStack/OpenStack-SIG-K8s team to handling tickets > and pull requests that come in to the Kubernetes hosted repository. > > My personal opinion is that we should take advantage of the Kubernetes > hosting, and migrate the project to one of the repositories listed in > the WG-Cloud-Provider patch. This wouldn't preclude moving it into > OpenStack infra hosting at some point in the future and possibly > adopting the hybrid approach down the line after more communication with > K8s infrastructure leaders. > > There is a sense of urgency, as Dims has asked that we relieve him of > the responsibility of hosing the external provider work in his personal > GitHub repository. > > Please chime in with your opinions on this here so that we can work out > an where the appropriate hosting for this project should be. > > Thanks, > Chris Hoge > K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead > > [1] https://github.com/dims/openstack-cloud-controller-manager > [2] https://github.com/kubernetes/community/pull/1862 > [3] https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev