All,
We've got some requirements around adding some interfaces to the heat
environment file format, for example:
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.
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.
such that we
could add an API (in addition to the one added by jdob to retrieve the
merged environment for a running stack) that can retrieve
all-the-environments and we can easily tell which one does what (e.g to
display in a UI perhaps)
I'm not sure I follow. Are you saying the API would return the list of
descriptions, or the actual contents of each environment file that was
passed in?
Currently, the environment is merged before we do anything with it. We'd
have to change that to store... I'm not entirely sure. Multiple
environments in the DB per stack? Is there a raw_environment in the DB
that we would leverage?
2. We've got requirements around merge strategies for multiple environments
with potentially colliding keys. Similar to the cloud-init merge
strategy[1] works. Basically it should be possible to include multiple
environments then have heat e.g append to a list parameter_default instead
of just last-one-wins.
Both of these will likely require some optional additions to the
environment file format - can we handle them just like e.g event_sinks and
just add them?
Clearly since the environment format isn't versioned this poses a
compatibility problem if "new" environments are used on an old heat, but to
be fair we have done this before (with both parameter_defaults and
event_sinks)
What do folks think, can we add at least the description, and what
interface makes sense for the merge strategy (annotation in the environment
vs data passed to the API along with the environment files list?)
Any thoughts on the above would be great :)
Thanks,
Steve
[1] http://cloudinit.readthedocs.io/en/latest/topics/merging.html
[2]
https://github.com/openstack/python-heatclient/blob/master/heatclient/common/environment_format.py#L22
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
