On 8.6.2016 11:15, Steven Hardy wrote:
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
__________________________________________________________________________
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
I'd like to revive this discussion. Fairly often the environment is used
to define certain feature. It would be really beneficial if environment
itself could carry its documentation and it was possible to
programmatically retrieve it. Optional metadata section would be IMHO a
good solution. HOT spec already has such section in template resources
section [1].
[1]
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#resources-section
-- Jirka
__________________________________________________________________________
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
