Open Stack

On 2013-05-02 10:39, Tripp, Travis S wrote:
>> -----Original Message-----
>> From: Thomas Spatzier [mailto:thomas.spatzier at de.ibm.com]
>> Sent: Thursday, May 02, 2013 1:25 AM
>> To: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat 
>> Providers
>> 
>> Clint Byrum <clint at fewbar.com> wrote on 29.04.2013 19:50:22:
>> 
>>> From: Clint Byrum <clint at fewbar.com>
>>> To: openstack-dev <openstack-dev at lists.openstack.org>,
>>> Date: 29.04.2013 19:51
>>> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
>> Providers
>>> 
>>> So I think the message here is that there are two concepts that 
>>> should
>>> be expressable separately:
>>> 
>>> * I have app X, which needs informational bits a,b, and c, from 
>>> other
>>> parts of my stack.
>>> 
>>> * I want to run app X on a compute resource with properties y and z.
>>> 
>>> So, it would be useful if the DSL is able to express things things
>>> separately.
>> 
>> I did not fully get the two points above. Can you elaborate more or 
>> give an
>> example?
>> 
>>> 
>>> As another data point, the juju project still struggles with this
>> concept,
>>> and it has been a real sticking point for a lot of users to not be
>>> able to assemble their apps separate from their resources.
>>> 
> 
> [Tripp, Travis S]
> 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.
> 
> I attached a quick diagram to illustrate the scenario.
> 

Indeed, the diagram did communicate the scenario exactly as I see it.