Open Stack

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).

The question here is how do we manage the interface between those two 
parts. In doing so, there are two things I firmly believe we need to avoid:

1) Writing our own configuration management
  - This is not a good use of the OpenStack project's resources. There is
    no particular reason to think we could do it any better than existing
    solutions. Even if we could the result does not belong in OpenStack,
    since it would be just as desirable in other contexts.

2) Depending on one particular configuration management tool
  - Neither is there any particular reason to think that the existing
    solutions are the best that will ever exist, nor that one can ever
    be universal. If we lock OpenStack in to one particular tool, we
    also lock out any future innovation in the field and all users for
    whom that tool does not work.


One thing that would be very useful to me - and maybe the folks with 
TOSCA experience would be well-placed to help out here - would be to 
describe what Heat would actually _do_ to deploy an application, with a 
focus on data flow, rather than just looking at what the template would 
look like.

Maybe take Travis's excellent diagram as a starting point. Where would 
App Part A and App Part B be defined? Where would the deployments be 
defined? Which actors could define them and their constituent parts? How 
would Heat combine the data? What calls would Heat end up making as a 
result?

Subject to the two constraints above, I am very supportive of this 
concept. But I still don't feel like I understand how it would work in 
practice.

cheers,
Zane.