Open Stack

>
> I suppose we disagree on this fundamental point then.
>
> Heat's value-add really does come from solving this exact problem. It
> provides a layer above all of the other services to facilitate expression
> of higher level concepts. Nova exposes a primitive API, where as Heat is
> meant to have a more logical expression of the user's intentions. That
> includes exposure of details of one resource to another (not just compute,
> swift containers, load balancers, volumes, images, etc).
>

That's a great vision for Heat, and I look forward to using it.

Heat is meant to be a facility for exactly what you want. If you don't
> want to ask people to use it, you're just duplicating Heat functionality
> in Nova. Using Heat means no query/filter for the instances you want:
> you have the exact addresses in your cluster.
>
> My suggestion would be that if you want to hide all of the complexity
> of Heat from users, you add a simplified API to Heat that enables your
> use case. In many ways that is exactly what Savanna, Trove, et.al are:
> domain specific cluster API's backed by orchestration.
>

I take it as a +1 for the feature that so many projects are suggesting that
they should be the one to implement it.  Given that there are so many
projects that feel they should have implemented it, this tells me that it
may in fact be common functionality, and thus we should put it into the
low-level project, i.e. Nova.

I don't think this should preclude Heat, Marconi, Neutron and any other
project in our big happy family from also implementing the feature, or from
doing it more completely using their domain-specific knowledge.  This is
open-source after all :-)

Justin

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/e206b07d/attachment.html>