Open Stack

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-request at 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