Open Stack

On 11/25/2015 03:17 PM, Jay Dobies wrote:
>>> I think at the same time we add a mechanism to distinguish between
>>> internal and external parameters, we need to add something to indicate
>>> required v. optional.
>>>
>>> With a nested stack, anything that's not part of the top-level 
>>> parameter
>>> contract is defaulted. The problem is that it loses information on what
>>> is a valid default v. what's simply defaulted to pass validation.
>>
>> I thought the nested validation spec was supposed to handle that though?
>>   To me, required vs. optional should be as simple as "Does the 
>> parameter
>> definition have a 'default' key?  If yes, then it's optional, if no,
>> then it's required for the user to pass a value via a parameter or
>> parameter_default".  I realize we may not have been following that up to
>> now for various reasons, but it seems like Heat is already providing a
>> pretty explicit mechanism for marking params as required, so we ought to
>> use it.
>
> Ya, I was mistaken here. Taking a look at the cinder-netapp.yaml, it 
> looks like we're using this correctly:
>
> ...
>   CinderNetappBackendName:
>     type: string
>     default: 'tripleo_netapp'
>   CinderNetappLogin:
>     type: string
>   CinderNetappPassword:
>     type: string
>     hidden: true
> ...
>
>
> __________________________________________________________________________ 
>
> 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 need to read the thread once again, but I'd like to add a few 
observations from the GUI implementation:

The nested validation as it works right now, requires that all root 
template parameters need to have 'default' or 'value' set, otherwise the 
heat validation fails and no parameters are returned. This is a sort of 
a blocker because we need to use this to retrieve the parameters and let 
user set the values for them. This means, that to be able to list the 
parameters, we need to make sure that all root template parameters have 
'default' set, which is not optimal.

Other observation (maybe a bit outside of the topic) is that the list of 
parameters defined in root template is huge, It would be nice if root 
template and more possibly root environment included resource registry 
only for the roles/templates that are explicitly required for the 
minimal deployment (controller, compute) and split other roles into 
separate  optional environments.
In current situation the user is required to set flavors, node counts 
etc. for all roles defined in root template even though he is not going 
to use them (sets the node_count to 0)


Jirka