Open Stack

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>