Open Stack

On 23/06/15 06:49, Thomas Spatzier wrote:
>> From: Jay Dobies <jason.dobies at redhat.com>
>> To: openstack-dev at lists.openstack.org
>> Date: 22/06/2015 19:22
>> Subject: Re: [openstack-dev] [heat][tripleo]Recursive validation for
>> easier composability
>>
>>
>>
>> On 06/22/2015 12:19 PM, Steven Hardy wrote:
>>> Hi all,
>>>
>>> Lately I've been giving some thought to how we might enable easier
>>> composability, and in particular how we can make it easier for folks to
>>> plug in deeply nested optional extra logic, then pass data in via
>>> parameter_defaults to that nested template.
>>>
>>> Here's an example of the use-case I'm describing:
>>>
>>> https://review.openstack.org/#/c/193143/5/environments/cinder-
>> netapp-config.yaml
>>> Here, we want to allow someone to easily turn on an optional
> configuration
>>> or feature, in this case a netapp backend for cinder.
>> I think the actual desired goal is bigger than just optional
>> configuration. I think it revolves more around choosing a nested stack
>> implementation for a resource type and how to manage custom parameters
>> for that implementation. We're getting into the territory here of having
>> a parent stack defining an API that nested stacks can plug into. I'd
>> like to have some sort of way of deriving that information instead of
>> having it be completely relegated to outside documentation (but I'm
>> getting off topic; at the end I mention how I want to do a better write
>> up of the issues Tuskar has faced and I'll elaborate more there).
> FWIW, adding a thought from my TOSCA background where we've been looking at
> something similar, namely selecting a nested templates that declares to be
> matching an interfaces consumed in a parent template (that's how I
> understood Jay's words above). In TOSCA, there is a more type-safe kind of
> template nesting, where nested templates do not just bring new resource
> types into existence depending on what parameters they expose, but there is
> a strict contract on the interface a nested template must fulfil - see [1],
> and especially look for substitution_mapping.
>
> Admittedly, this is not exactly the same as Steven's original problem, but
> kind of related. And IIRC, some time back there was some discussion around
> introduction of some kind of "interface" for HOT templates. So wanted to
> bring this in and give it some thought whether something like this would
> make sense for Heat.
>
> [1]
> http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csd03/TOSCA-Simple-Profile-YAML-v1.0-csd03.html#_Toc419746122

This sounds like the dormant blueprint interface-types [2]. I still 
think it would be appropriate to support this at the heat layer even 
though Murano ended up keeping their interface implementation at the 
Murano layer.

Interfaces is slightly different to how to set parameters on deeply 
nested stacks though.

[2] https://blueprints.launchpad.net/heat/+spec/interface-types