<snip...> > parameters: > env: > type: string > default: prod > > is_prod: > type: boolean > default: {equals: {get_param, env}} > > From an interface standpoint this seems much cleaner and more intuitive than > the other solutions discussed IMHO, but I suspect it's potentially harder to > implement. > > Your original example gets much cleaner too if we allow all intrinsic function > (except get_attr) in the scope of parameters: > > parameters: > host: > type: string > port: > type: string > endpoint: > type: string > default: > str_replace: > template: > http://HOSTORT/ > params: > HOST: {get_param: host} > PORT: {get_param: port} > > Steve
+1 to restricting the variable evaluation into the 'parameters' section which we can treat as the 'static' part of a template. Maybe that is one of the reasons why aws has a 'conditions' section to avoid getting into the lazy evaluation mess? Regards, Qiming __________________________________________________________________________ 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