Open Stack

On Wed, Jun 8, 2016 at 11:23 AM, Steven Hardy <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.


-- Jirka


> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160608/7f23204c/attachment.html>