[openstack-dev] [heat][TripleO] Adding interfaces to environment files?
shardy at redhat.com
Wed Jun 8 09:23:06 UTC 2016
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
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
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:
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
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
More information about the OpenStack-dev