Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>