Params have the added advantage that horizon could be potentially tweaked to do form validation in the ui based in it.
Thanks, Kevin ________________________________ From: Steven Hardy Sent: Friday, April 01, 2016 9:31:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote: > On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <[email protected]> wrote: > > On 31/03/16 18:10, Zane Bitter wrote: > >> > >> > >> I'm in favour of some sort of variable-based implementation for a few > >> reasons. One is that (5) seems to come up fairly regularly in a complex > >> deployment like TripleO. Another is that Fn::If feels awkward compared > >> to get_variable. > > > > > > I actually have to revise this last part after reviewing the patches. > > get_variable can't replace Fn::If, because we'd still need to handle stuff > > of the form: > > > > some_property: {if: [{get_variable: some_var}, > > {get_resource: res1}, > > {get_resource: res2}] > > > > where the alternatives can't come from a variable because they contain > > resource references and we have said we'd constrain variables to be static. > > > > In fact the intrinsic functions that could be allowed in the first argument > > to the {if: } function would have to constrained in the same way as the > > constraint field in the resource, because we should only validate and obtain > > dependencies from _one_ of the alternates, so we need to be able to > > determine which one statically and not have to wait until the actual value > > is resolved. This is possibly the strongest argument for keeping on the cfn > > implementation course. > > We talked about another possibilities on IRC: instead of having a new > section, create a new resource OS::Heat::Value which can hold some > data. It would look like that: > > resources: > is_prod: > type: OS::Heat::Value > properties: > value: {equals: {get_param, env}, prod}} > > my_resource: > condition: {get_attr: [is_prod, value}} Another alternative (which maybe you discussed, sorry I missed the IRC chat) would be just to use parameters, as that's already conceptually where we obtain values that are input to resources. E.g: 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
