Open Stack

----- Original Message -----
> From: "Monty Taylor" <mordred at inaugust.com>
> To: openstack-dev at lists.openstack.org
> Sent: Sunday, April 2, 2017 4:16:44 PM
> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes
> 
> On 04/02/2017 02:53 PM, Chris Hoge wrote:
> > Now that the provider has a repository in the OpenStack project
> > namespace, we need to move over the existing set of issues and pull
> > requests and create an initial work list for migrating patches and
> > fixing existing issues.
> > 
> > I've started up an etherpad where we can track that work[1]. In the longer
> > run we should migrate over to Launchpad or Storyboard. One question,
> > to help preserve continuity with the K8S community workflow: do we want
> > to investigate ways to allow for issue creation in the OpenStack
> > namespace on GitHub?
> 
> I do not think this is a thing we want to do. While I understand the
> urge, a project needs to live somewhere (in this case we've chosen
> OpenStack) and should behave as projects do in that location. When I
> work on Ansible, I do issues on github. When I deal with tox, I file
> issues on bitbucket. Back when I dealt with Jenkins I filed issues in
> their Jira. I do not think that filing an issue in the issue tracker for
> a project is too onerous of a request to make of someone.
> 
> We have issues turned off in all of our github mirrors, so it's highly
> unlikely someone will accidentally attempt to file an issue like the.
> (it's too bad we can't similarly turn off pull requests, but oh well)

I agree with the above comments w.r.t. tooling, but I think we will still need to determine what I think is at the core of Chris's concern which is in a world where we have extracted the cloud provider implementation from Kube (and externalizing these from Kube has indeed been on the table for some time, so thanks Dims for taking the initiative) how do we continue to work on it in the OpenStack community while also still maintaining - if not extending - our level of interop and visibility with the Kubernetes community. I think the focus of concern here should be less on the tools though - as you note each community has its own tools and that is unlikely to change - and more on communication but it can be difficult to decouple the two (IRC versus Slack, Zoom, etc.).

Thus far discussion of open PRs/Issues and ongoing work w.r.t. the provider implementation has primarily focused on the Kubernetes OpenStack SIG (the scope of which was recently extended to allow space for discussions/collaboration between the various OpenStack deployment projects and folks anchored in the Kubernetes side of things, specifically w.r.t. Helm. It's not immediately clear to me how we would prefer to maintain visibility on the Kubernetes side of the fence going forward because a natural progression of "this is developed, tested, and served up on OpenStack infra" would of course also be to move most of these discussions to IRC.

Thanks,

Steve