On 06/13/2016 03:51 PM, Ben Nemec wrote:
On 06/08/2016 07:00 AM, Jiri Tomasek wrote:
On Wed, Jun 8, 2016 at 11:23 AM, Steven Hardy <sha...@redhat.com
<mailto:sha...@redhat.com>> wrote:
On Tue, Jun 07, 2016 at 04:53:12PM -0400, Zane Bitter wrote:
> On 07/06/16 15:57, Jay Dobies wrote:
> > >
> > > 1. Now that we support passing un-merged environment files to heat,
> > > it'd be
> > > good to support an optional description key for environments,
> >
> > I've never understood why the environment file doesn't have a
> > description field itself. Templates have descriptions, and IMO it makes
> > sense for an environment to describe what its particular additions to
> > the parameters/registry do.
>
> Just use a comment?
This doesn't work for any of the TripleO use-cases because you can't
parse
a comment.
The requirements are twofold:
1. Prior to creating the stack, we need a way to present choices to the
user about which environment files to enable. This is made much
easier if
you can include a human-readable description about what the environment
actually does.
2. After creating the stack, we need a way to easily introspect the
stack
and see what environments were enabled. Same as above, it's be
super-awesome if we could just then strip out the description of
what they
do, so we don't have to maintain hacks like this:
https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml
The description is one potentially easy-win here, it just makes far more
sense to keep the description of a thing inside the same file (just
like we
do already with HOT templates).
The next step beyond that is the need to express dependencies between
things, which is what I was trying to address via the
https://review.openstack.org/#/c/196656/ spec - that kinda stalled
when it
took 7 months to land so we'll probably need that capabilities_map
for that
unless we can revive that effort.
> > I'd be happy to write that patch, but I wanted to first double check
> > that there wasn't a big philosophical reason why it shouldn't have a
> > description.
>
> There's not much point unless you're also adding an API to retrieve
> environment files like Steve mentioned. Comments get stripped when the
yaml
> is parsed, but that's fairly academic if you don't have a way to get it
out
> again.
Yup, I'm absolutely proposing we add an interface to retrieve the
environment files (or, in fact, the entire stack files map, and a
list of
environment_files).
Steve
Hi, thanks for bringing this topic up. Capabilities map provides several
information about environments. We definitely need to get rid of it in
favor of having Heat provide this from the environment file metadata.
How much additional work would it be to enable environments provide more
metadata than just a description?
From the GUI point of view an information structure such as following
would be much appreciated:
environments/environments/net-bond-with-vlans.yaml:
meta:
label: Net Bond with Vlans
description: >
Configure each role to use a pair of bonded nics (nic2 and
nic3) and configures an IP address on each relevant isolated network
for each role. This option assumes use of Network Isolation.
requires:
- environments/network-isolation.yaml
- overcloud-resource-registry-puppet.yaml
alternatives:
- environments/net-single-nic-with-vlans.yaml
group:
- network-configuration
Grouping of environments is a bit problematic. We could introduce
something like 'group' which could categorize the environments. Problem
is that each group would eventually require own entity to cover group
label and description.
This is why I actually don't think grouping information belongs in the
environment files at all. I left some related thoughts in a response to
Steve on https://review.openstack.org/#/c/253638/ but mostly it boils
down to the fact that the group metadata is at a different level from
the environments so putting it in the environment is a bad fit.
Note that the same applies to alternatives. Putting requirements in the
environments makes perfect sense, but making them be aware of all their
siblings too gets messy (consider that if we add a single new network
environment now all of the existing environments would have to be
updated as well).
Yeah, makes perfect sense. Alternative solution could be that we
maintain groups in separate meta file such as capabilities map which is
tied to a repository and maps that files in it. I am aware that it
brings additional maintenance to the repo, but the difference to
capabilities-map is that this meta file would be totally optional.
Question is how hard would it be to implement Heat support for such meta
file, so Heat could use it's information and combine it with
environments meta.
By not having 'groups' user is presented with somewhat chaotic list of
environments to choose from. Not having 'alternatives' means that it is
up to user to know this information.
A great thing is that (as Steven mentioned previously) the environment
merging is going to be done on Heat side. Environment meta data could
include the merging strategy information relevant to that specific
environment. This could be used to determine environment alternatives:
An environment with 'merging_strategy: restrictive' is an 'alternative'
to other such environment which defines the same resource in
resource_registry. If 2 environments define the same resource in
resource registry and one is 'permissive' and other is 'restrictive',
they can be merged but the order matters 'permissive' needs to be
overriden by 'restrictive'. If both (all) environments are 'permissive'
then the order they're applied in should not matter. I am not 100% sure
this is applicable solution, please take it as a feed for thought.
Although the environments which define the same resource are IMHO safe
to be considered an alternatives.
In addition it would be probably nice if Heat would not restrict the
meta values which are possible to be set in environment and return all
meta values which are defined in environment.
-- Jirka
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
