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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
