On 08/06/18 02:40, Rico Lin wrote:
Thanks, Zane for putting this up.
It's a great service to expose infrastructure to application, and a
potential cross-community works as well.
>
> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and let's collect a list of volunteers
> to form the initial core review team.
>
Glad to help
> I'd prefer to go with the pure-Ansible autogenerated way so we can have
> support for everything, but looking at the GCP[5]/Azure[4]/AWS[3]
> brokers they have 10, 11 and 17 services respectively, so arguably we
> could get a comparable number of features exposed without investing
> crazy amounts of time if we had to write templates explicitly.
>
If we going to generate another project to provide this service, I
believe to use pure-Ansible will be a better option indeed.
TBH I don't think we can know for sure until we've tried building a few
playbooks by hand and figured out whether they're similar enough that we
can autogenerate them all, or if they need so much hand-tuning that it
isn't feasible. But I'm a big fan of autogeneration if it works.
Once service gets stable, it's actually quite easy(at first glance) for
Heat to adopt this (just create a service broker with our new service
while creating a resource I believe?).
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 ;)
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 ;)
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.
Sounds like the use case of service broker might be when application
request for a single resource exposed with Broker. And the resource
dependency will be relatively simple. And we should just keep it simple
and don't start thinking about who and how that application was created
and keep the application out of dependency (I mean if the user likes to
manage the total dependency, they can consider using heat with service
broker once we integrated).
--
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
