On 06/06/18 11:18, Chris Hoge wrote:
Hi Zane,
Do you think this effort would make sense as a subproject within the Cloud
Provider OpenStack repository hosted within the Kubernetes org? We have
a solid group of people working on the cloud provider, and while it’s not
the same code, it’s a collection of the same expertise and test resources.
TBH, I think it makes more sense as part of the OpenStack community. If
you look at how the components interact, it goes:
Kubernetes Service Catalog -> Automation Broker -> [this] -> OpenStack
So the interfaces with k8s are already well-defined and owned by other
teams. It's the interface with OpenStack that requires the closest
co-ordination. (Particularly if we end up autogenerating the playbooks
from introspection on shade.) If you look at where the other clouds host
their service brokers or Ansible Playbook Bundles, they're not part of
the equivalent Kubernetes Cloud Providers either.
We'll definitely want testing though. Given that this is effectively
another user interface to OpenStack, do you think this is an area that
OpenLab could help out with?
Even if it's hosted as an OpenStack project, we should still make sure
we have documentation and pointers from the kubernetes/cloud-provider-openstack
to guide users in the right direction.
Sure, that makes sense to cross-advertise it to people we know are using
k8s on top of OpenStack already. (Although note that k8s does not have
to be running on top of OpenStack for the service broker to be useful,
unlike the cloud provider.)
While I'm not in a position to directly contribute, I'm happy to offer
any support I can through the SIG-OpenStack and SIG-Cloud-Provider
roles I have in the K8s community.
Thanks!
cheers,
Zane.
__________________________________________________________________________
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
