[openstack-dev] [openstack-tc] 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-dev
mailing list