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