Open Stack

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 <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).

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-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
>>
>
> __________________________________________________________________________
> 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