Re: [openstack-dev] [k8s] Hosting location for OpenStack Kubernetes Provider

2018-03-22 Thread Davanum Srinivas
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  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


[openstack-dev] [k8s] Hosting location for OpenStack Kubernetes Provider

2018-03-13 Thread Chris Hoge
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