Open Stack

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