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-requ...@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
__________________________________________________________________________
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
