Open Stack

On 2013-05-10 07:17, Thomas Spatzier wrote:
> Those nested templates (or just templates - you could use them 
> stand-alone)
> are providers for "2 tier hosting environment". Now if we pick up the
> "Environments" idea from Adrian's DSL wiki page, we could define an
> environment TEST where we say to use "TinyDeployment" as provider for 
> the 2
> tier hosting env, and in PROD we say to use "LargeDeployment" (see
> diagram). So when the orchestration engine is asked to find a 
> realization
> for 2 tier hosting env, it selects it depending on the environment you
> deploy to.
> 
> Here are some snippets to outline how the templates could look like:
> 
> The app-layer model would be:
> 
> # application layer template
> # all the header info, inputs, ...
> 
> components:
>   # some software component
>   comp_a:
>     type: os::heat::softwareconfig::chef_solo
>     # all the details of comp_a
>     requires:
>       # c1 means tier1 slot of hosting env
>       hosted_on: hosting_env.c1
>       # comp_a needs to connect to comp_b
>       connects_to: comp_b
> 
>   # some other software component
>   comp_b:
>     type: os::heat::softwareconfig::chef_solo
>     # all the details of comp_b
>     requires:
>       # c2 means tier2 slot of hosting env
>       hosted_on: hosting_env.c2
> 
>   # representation/placeholder for hosting env
>   # where details are provided in separate template
>   hosting_env:
>     # assumes that there is a provider for my::custom::2_tier_env
>     # which can be a nested template
>     type: my::custom::2_tier_env
> 
> 
> Note the "hosting_env" component which just says it is of a specific 
> type.
> The orchestration engine will have to look for that type at deployment
> time. It will also have to figure out what .c1 and .c2 mean (it's like
> slots that the 2_tier_env component offers, but this is in the nested
> templates).
> Basically, what the orchestrator does when resolving the abstract 
> component
> "hosting_env" to one of the two infrastructure templates is to merge 
> two
> graphs into one based on clear contracts and then run the merged graph 
> thru
> normal orchestration.
> 
> The TinyDeployment template could look like this:
> 
> # TinyDeployment 2 tier hosting env template
> # all the header info ...
> 
> implements:
>   tiny_env: # this is an arbitrary label
>     type: my::custom::2_tier_env # this is what is actually 
> implemented
>     provides:
>       c1:
>         type: os::nova::compute
>         provided_by: server
>       c2:
>         type: os::nova::compute
>         provided_by: server
> 
> components:
>   server:
>     type: os::nova::compute
> 
> 
> This defines one server, declares that the template implements the
> 2_tier_env component, and exposes two compute capabilities, which are 
> both
> realized by the single server.
> 
> The LargeDeployment template would be:
> 
> # LargeDeployment 2 tier hosting env template
> # all the header info ...
> 
> implements:
>   large_env: # this is an arbitrary label
>     type: my::custom::2_tier_env # this is what is actually 
> implemented
>     provides:
>       c1:
>         type: os::nova::compute
>         provided_by: server1
>       c2:
>         type: os::nova::compute
>         provided_by: server2
> 
> components:
>   server1:
>     type: os::nova::compute
> 
>   server2:
>     type: os::nova::compute


Whether this fits the final format or not, I like it a lot. This level 
of abstraction is precisely what I am looking for out of the HOT format.