Open Stack

Angus,

On Apr 11, 2013, at 11:11 PM, Angus Salkeld <asalkeld at redhat.com>
 wrote:

> On 12/04/13 00:03 +0000, Adrian Otto wrote:
>> Heat Team,
>> 
>> On Apr 9, 2013, at 11:24 PM, Clint Byrum <clint at fewbar.com> wrote:
>> 
>> [snip]
>>> * Open DSL w/ Declarative model(undefined yet)
>> 
>> [snip]
>> 
>> Here is the definition of what we are willing to contribute to Heat.
>> 
>> https://blueprints.launchpad.net/heat/+spec/open-api-dsl
>> https://wiki.openstack.org/wiki/Heat/DSL
>> https://wiki.openstack.org/wiki/Heat/Open_API
>> 
>> Rackspace has a production Python implementation of this that has a year's worth of refinement since the first working prototype. We see this as one of several template formats that Heat could support. Pursuit of this DSL would not preclude us from also adding TOSCA and CAMP compliance, when those are desired. The Heat/Open_API Wiki page offered as a minimalistic description of the simplest API that will fully support the functionality in the DSL.
>> 
>> Please note that this is not written as a full specification. It's not detailed enough to write a new implementation from without additional detail. However, it should give you a good idea of how our contribution would work.
> 
> That is a good start, can you put a complete working dsl-blueprint? These
> sometimes more sense when you can see a full example or two.

There are three currently shown on the Wiki:

https://wiki.openstack.org/wiki/Heat/DSL#Heat_Blueprint_Examples

We might want to take the … out of the second one, as that's trying to express that you can add more services in there, but perhaps it's giving the impression that somethings missing. We will also add a few more examples to give everyone a better sense of what they look like in a variety of use cases.

> Given we are in OpenStack and we use launchpad blueprints, my first
> suggestion is to rename the dsl-blueprint so we don't have to keep
> doing this -> "dsl-blueprint". (template/recipe/plan/spec/whatever)

Let's not get stalled on the taxonomy for now. We are definitely willing to revisit this once we are ready for discussing the finer points.

> If you are quick we can look over it our flights to summit.
> 
> The other part that is missing is what guest agent you require/use and how the agent and engine communicate.

This proposal will utilize the existing Heat agent. We currently use SSH keypair injection on the API call to the Cloud Servers API to bootstrap compute nodes in the simple case. The idea is to leave that open to handle whatever the system Provider modules want to instrument. Please recognize that we want this DSL to work regardless of what the underlying hardware/cloud infrastructure is. It can work on your laptop with vagrant, with OpenStack, with a public cloud… that should not matter. The vendor specific implementations all go into the Provider plug-ins. The idea is to enable decentralized implementation of vendor-specific systems, and centralized sharing of best practices for application deployment. Imagine an OpenStack community repo of Heat Blueprints where everyone can publish their best practices.

Thanks,

Adrian

> 
> 
> Thanks
> -Angus
> 
>> 
>> I will also file at least one other Blueprint about modularity, which is partially enabled by this proposal.
>> 
>> Regards,
>> 
>> Adrian Otto
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev