Zane Bitter <[email protected]> 於 2018年6月9日 週六 上午9:20寫道： > > IIUC you're talking about a Heat resource that calls out to a service > broker using the Open Service Broker API? (Basically acting like the > Kubernetes Service Catalog.) That would be cool, as it would allow us to > orchestrate services written for Kubernetes/CloudFoundry using Heat. > Although probably not as easy as it sounds at first glance ;) In my previous glance, I was thought about our new service will also wrap up API with Ansible playbooks. A playbook to create a resource, and another playbook to control Service Broker API. So we can directly use that playbook instead of calling Service broker APIs. No?:)
I think we can start trying to build playbooks before we start planning on crazy ideas:) > > It wouldn't rely on _this_ set of playbook bundles though, because this > one is only going to expose OpenStack resources, which are already > exposed in Heat. (Unless you're suggesting we replace all of the current > resource plugins in Heat with Ansible playbooks via the service broker? > In which case... that's not gonna happen ;) Right, we should use OS::Heat::Stack to expose resources from other OpenStack, not with this. > > So Heat could adopt this at any time to add support for resources > exposed by _other_ service brokers, such as the AWS/Azure/GCE service > brokers or other playbooks exposed through Automation Broker. > I like the idea to add support for resources exposed by other service borkers -- May The Force of OpenStack Be With You, Rico Lin 林冠宇
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
