<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 11:23 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Tue, Jun 07, 2016 at 04:53:12PM -0400, Zane Bitter wrote:<br>
> On 07/06/16 15:57, Jay Dobies wrote:<br>
> > ><br>
> > > 1. Now that we support passing un-merged environment files to heat,<br>
> > > it'd be<br>
> > > good to support an optional description key for environments,<br>
> ><br>
> > I've never understood why the environment file doesn't have a<br>
> > description field itself. Templates have descriptions, and IMO it makes<br>
> > sense for an environment to describe what its particular additions to<br>
> > the parameters/registry do.<br>
><br>
> Just use a comment?<br>
<br>
</span>This doesn't work for any of the TripleO use-cases because you can't parse<br>
a comment.<br>
<br>
The requirements are twofold:<br>
<br>
1. Prior to creating the stack, we need a way to present choices to the<br>
user about which environment files to enable.  This is made much easier if<br>
you can include a human-readable description about what the environment<br>
actually does.<br>
<br>
2. After creating the stack, we need a way to easily introspect the stack<br>
and see what environments were enabled.  Same as above, it's be<br>
super-awesome if we could just then strip out the description of what they<br>
do, so we don't have to maintain hacks like this:<br>
<br>
<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml</a><br>
<br>
The description is one potentially easy-win here, it just makes far more<br>
sense to keep the description of a thing inside the same file (just like we<br>
do already with HOT templates).<br>
<br>
The next step beyond that is the need to express dependencies between<br>
things, which is what I was trying to address via the<br>
<a href="https://review.openstack.org/#/c/196656/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/196656/</a> spec - that kinda stalled when it<br>
took 7 months to land so we'll probably need that capabilities_map for that<br>
unless we can revive that effort.<br>
<span class=""><br>
> > I'd be happy to write that patch, but I wanted to first double check<br>
> > that there wasn't a big philosophical reason why it shouldn't have a<br>
> > description.<br>
><br>
> There's not much point unless you're also adding an API to retrieve<br>
> environment files like Steve mentioned. Comments get stripped when the yaml<br>
> is parsed, but that's fairly academic if you don't have a way to get it out<br>
> again.<br>
<br>
</span>Yup, I'm absolutely proposing we add an interface to retrieve the<br>
environment files (or, in fact, the entire stack files map, and a list of<br>
environment_files).<br>
<br>
Steve<br></blockquote><div><br></div><div><br></div><div>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?</div><div><br></div><div>From the GUI point of view an information structure such as following would be much appreciated:</div><div><br></div><div>environments/environments/net-bond-with-vlans.yaml:</div><div><br></div><div><font face="monospace, monospace">meta:</font></div><div><font face="monospace, monospace">  label: Net Bond with Vlans</font></div><div><font face="monospace, monospace">  description: ></font></div><div><font face="monospace, monospace">    Configure each role to use a pair of bonded nics (nic2 and</font></div><div><font face="monospace, monospace">    nic3) and configures an IP address on each relevant isolated network</font></div><div><font face="monospace, monospace">    for each role. This option assumes use of Network Isolation.</font></div><div><font face="monospace, monospace">  requires:</font></div><div><font face="monospace, monospace">    - environments/network-isolation.yaml</font></div><div><font face="monospace, monospace">    - overcloud-resource-registry-puppet.yaml</font></div><div><font face="monospace, monospace">  alternatives:</font></div><div><font face="monospace, monospace">    - environments/net-single-nic-with-vlans.yaml</font></div><div><font face="monospace, monospace">  group:</font></div><div><font face="monospace, monospace">    - network-configuration</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div><div><br></div><div><br></div><div><font face="arial, helvetica, sans-serif">-- Jirka</font></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>