<div dir="ltr">Thanks, Zane for putting this up.<div>It's a great service to expose infrastructure to application, and a potential cross-community works as well.<br><div>><br>> Would you be interested in working on a new project to implement this<br>> integration? Reply to this thread and let's collect a list of volunteers<br>> to form the initial core review team.<br>><div>Glad to help</div><div><br>> I'd prefer to go with the pure-Ansible autogenerated way so we can have<br>> support for everything, but looking at the GCP[5]/Azure[4]/AWS[3]<br>> brokers they have 10, 11 and 17 services respectively, so arguably we<br>> could get a comparable number of features exposed without investing<br>> crazy amounts of time if we had to write templates explicitly.<br>><br>If we going to generate another project to provide this service, I believe to use pure-Ansible will be a better option indeed.</div><div><br></div><div>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?).</div><div>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).<br><br>--<br>May The Force of OpenStack Be With You,<br><br>Rico Lin</div></div></div></div>