[openstack-tc] [openstack-dev] Motion to validate Heat's application as incubated project

Zane Bitter zbitter at redhat.com
Fri Oct 26 16:50:09 UTC 2012


On 26/10/12 15:57, Thierry Carrez wrote:
> Mark McLoughlin wrote:
>> >On Fri, 2012-10-26 at 14:30 +0200, Thierry Carrez wrote:
>>> >>The main issue I see with us entering this space is that there are many
>>> >>competing solutions out there. I'm not entirely convinced there is that
>>> >>much value in OpenStack picking one and somehow making the others
>>> >>second-class...
>> >
>> >Care to list the many competing solutions that you're concerned about
>> >making second-class?
> I was thinking about Juju, or cloud-oriented uses of Puppet/Chef.
> Autoscaling would also touch a number of management solutions (like Scalr).

It's worth pointing out that as well as configuring Nova instances and 
sets of instances, Heat allows you to set up Keystone users, Swift 
containers, Nova (in future, Cinder) volumes, and dynamic IP addresses. 
Planning is underway to add Quantum networks too 
(https://etherpad.openstack.org/grizzly-heat-quantum).

We already support spinning up predefined Nova instances for relational 
databases and load balancers (this is pretty similar to Juju), but in 
the future these can be moved over to OpenStack-native services like 
Reddwarf Lite or the oft-proposed LBaaS API as they become accepted by 
the community. Add a notification (message queue) service to that list 
too. That's just to get to parity with AWS, and there is no reason to 
stop there.

In short, Heat is about configuring _every_ service that is available in 
OpenStack, with auto-scaling and high availability, all from a template 
written in a simple declarative markup language. It's not just about 
launching instances and configuring the services on them - in fact if 
you want to use Puppet for that it complements Heat very nicely, and we 
even have a couple of example templates in the Heat repo to do it.

cheers,
Zane.



More information about the OpenStack-TC mailing list