Open Stack

This might be related but we have a talk/demo about recursive containers on
Thursday which allows you to build complex app topologies from simpler ones
(like lego blocks). The idea is old, is way-pre-HEAT (Boston summit) but
this current talk is more of how to visually/interactively provision such
topologies with openstack (and quantum).

debo


On Tue, Apr 2, 2013 at 4:23 PM, Angus Salkeld <asalkeld at redhat.com> wrote:

> On 02/04/13 22:46 +0000, Adrian Otto wrote:
>
>> Hello,
>>
>> Rackspace has resourced two dedicated development teams for the sole
>> purpose of contributing new features and capabilities to OpenStack's HEAT
>> project. We are very excited, and would like to share with you what we plan
>> to design and contribute together with you:
>>
>> 1) Open API & DSL - This allows templates to be agnostic to the
>> underlying cloud and encourages community contribution for the betterment
>> of all users across all cloud providers. We want a solution that does not
>> depend on semantics from any single service provider. We think there is a
>> way for HEAT to work equally well with CloudFormation templates, and a
>> completely open template format as well.
>>
>> 2) Declarative Model - Although CloudFormation Templates were designed to
>> be declarative, in practice the templates are very imperative artifacts
>> (for example, those that embed shell scripts). Templates that are expressed
>> using a declarative approach are compact, simple, and portable between
>> clouds that have different services available. We want the cloud
>> implementation specific details to be handled by modules, not wired into
>> the templates. Declarative modeling encourages broad contribution from the
>> user base to improve the overall community library of available solutions.
>> While modeling may be easy to implement, they are more difficult to expand
>> to support generic cloud portable use cases.
>>
>> 3) Modular Implementation - We want HEAT to be modular in a way that's
>> consistent with the level of modularity offered in Nova, Quantum, Cinder
>> and others where a common, extendable API is offered and a variety of
>> extensions may be added for various back-end services and features. We want
>> to keep the architecture as simple as possible while allowing individual
>> cloud operators to add features and capabilities in a way that keeps
>> templates crisp and portable.
>>
>> 4) Auto-Scale Implementation - The solution will allow deployments to
>> scale up and down dynamically based on demand. We want to design and
>> implement this with you. We have considerable experience and resources to
>> bring with us. We have a dedicated team to contribute solutions here.
>>
>> We look forward to discussing more with you at the Summit in Portland.
>> Leaders from each of our new teams will be there ready to work with you on
>> implementation details.
>>
>
> Welcome to the Heat community!
>
> Great news, it will be good to see you at summit.
>
> -Angus
>
>
>> Regards,
>>
>> Adrian Otto
>>
>
>  ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 
-Debo~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130403/7aa755c2/attachment.html>