Open Stack

Clint Byrum <clint at fewbar.com> wrote on 10.05.2013 17:39:00:

> From: Clint Byrum <clint at fewbar.com>
> To: <openstack-dev at lists.openstack.org>,
> Date: 10.05.2013 17:39
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
Providers
>
> 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.

Good to see this made sense to you :-) No question the final HOT format
still needs some work, but for features like this kind of model composition
and substitutability we might not have to wait for each bit to be resolved.
I am actually asking myself how to best get going and adding stuff we need
incrementally. So here are a couple of thoughts:
We have some yaml sample being created in the core HOT discussion. Maybe we
could just add a hook in the code at the right spot shielded by a switch
(--format=hot | --format=cfn which would be the default for now) and get
some exprience with the samples. Based on a first simple version of this,
we could add features for the use case discussed in this thread. I.e. add
such new features in HOT, and keep cfn as it is. The
"composability/substitutability" item could then go on in parallel without
being to much gated by the general HOT definition. The HOT definition
itself could also benefit by turning from conceptual level to running code.
I guess this could help to break the problem down, seeing if any BPs
already map to lower level work items, identify missing BPs etc.

We had a G+ hangout with some folks about two weeks ago. I will probably
see to get another one set up with the same group so we can make some
progress.

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>