Open Stack

On Tue, Jun 07, 2016 at 03:57:31PM -0400, Jay Dobies wrote:
> > 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.

AFAIK there are two reasons:

1. Until your recent work landed, any description would be destroyed by the
client when it merged the environments

2. We've got no way to retrieve the environment descriptions from heat (as
Zane mentioned in his reply).

I'm suggesting we fix (2) as a followup step to your work to add an API
that returns the merged environment, e.g add an API that returns the files
map associated with a stack, and one that can list the environments in use
(not just the resolved/merged environment).

> > 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?

The actual contents, either by passing a list of environment filenames, and
providing another API that can return the files map containing the files,
or by having one API call that can return a map of filenames to content for
all environments passed via environment_files.

Basically, I think we should expose all data as passed to create_stack in
it's original form, and (as you already added) in it's post-processed form
e.g the merged environment.

> 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?

We just need to store the environment_files list - we already store the
environment files in the files map

https://review.openstack.org/#/c/241662/17/heat/engine/service.py

So, we need to store environment_files as well as the output of
_merge_environments, then add some sort of API to expose both that list and
the files map.

Steve