Open Stack

On 2013-05-06 07:38, Zane Bitter wrote:
> On 02/05/13 19:39, Tripp, Travis S wrote:
>> I agree with Clint.  This essentially boils down to being able to 
>> describe my application(s) and how to deploy them separately from the 
>> resources where I want to deploy them. Then based on the target 
>> environment, I have a way to deploy my app to different resources 
>> without having to modify / copy paste my app model everywhere.  In 
>> TOSCA terms, this is what the "relationship" concept provides. For 
>> example, I can design my application in one template and 
>> infrastructure(s) in another template. Then I essentially can have 
>> different deployments where I use the relationship to establish a 
>> source and a target for these relationship (App part A is associated 
>> to Infra part X). I just spoke with Thomas Spatzier and I think he is 
>> going to provide a simplified JSON or YAML representation of this 
>> concept.
> 
> This use case makes complete sense to me.
> 
> Here's the part I'm struggling with:
> 
>> For example, I can design my application in one template and 
>> infrastructure(s) in another template.
> 
> So... this exists, right?
> 
> We call the first part "configuration management" (Puppet, Chef) and
> the second part "cloud orchestration" (Heat, CloudFormation).
> 

As Thomas said, this is not really the case I'm talking about.

Notice here:

https://github.com/openstack-ops/templates/blob/master/heat.yaml

All the things to deploy the Heat engine on one machine, and the API's 
all together in a scaling group.

https://github.com/openstack-ops/templates/blob/master/keystone.yaml

All the things to deploy Keystone on an instance group.

You'll notice a complete lack of configuration management there. We use 
Metadata to drive os-config-applier and os-refresh-config, which are the 
TripleO minimalistic "config management" equivalents.

What I'd like to do is run keystone and heat-api's on a single instance 
group which encompass all of my stateless API services. To do that, I 
have to duplicate *most* of the templates I've already written, only 
with the metadata merged.

So, I submit that there need to be a way to specify an abstract 
resource which has the Metadata/Parameters/Relationships needed to 
deploy said resource, but does not have the machine placement details. 
Those would then be included in the instance groups, something like:

IncludeMetadata:
   - HeatAPIMetadata
   - KeystoneMetadata

I believe what Thomas is saying is that TOSCA already has sophisticated 
ways to express this concept.