Open Stack

On 06/08/2016 07:00 AM, Jiri Tomasek wrote:
> 
> On Wed, Jun 8, 2016 at 11:23 AM, Steven Hardy <shardy at redhat.com
> <mailto:shardy at 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).

> 
> 
> -- Jirka
> 
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>