<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Params have the added advantage that horizon could be potentially tweaked to do form validation in the ui based in it.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Steven Hardy<br>
<b>Sent:</b> Friday, April 01, 2016 9:31:45 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] µªÎ`: [Heat] Re-evaluate conditions specification<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote:<br>
> On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <zbitter@redhat.com> wrote:<br>
> > On 31/03/16 18:10, Zane Bitter wrote:<br>
> >><br>
> >><br>
> >> I'm in favour of some sort of variable-based implementation for a few<br>
> >> reasons. One is that (5) seems to come up fairly regularly in a complex<br>
> >> deployment like TripleO. Another is that Fn::If feels awkward compared<br>
> >> to get_variable.<br>
> ><br>
> ><br>
> > I actually have to revise this last part after reviewing the patches.<br>
> > get_variable can't replace Fn::If, because we'd still need to handle stuff<br>
> > of the form:<br>
> ><br>
> > some_property: {if: [{get_variable: some_var},<br>
> > {get_resource: res1},<br>
> > {get_resource: res2}]<br>
> ><br>
> > where the alternatives can't come from a variable because they contain<br>
> > resource references and we have said we'd constrain variables to be static.<br>
> ><br>
> > In fact the intrinsic functions that could be allowed in the first argument<br>
> > to the {if: } function would have to constrained in the same way as the<br>
> > constraint field in the resource, because we should only validate and obtain<br>
> > dependencies from _one_ of the alternates, so we need to be able to<br>
> > determine which one statically and not have to wait until the actual value<br>
> > is resolved. This is possibly the strongest argument for keeping on the cfn<br>
> > implementation course.<br>
> <br>
> We talked about another possibilities on IRC: instead of having a new<br>
> section, create a new resource OS::Heat::Value which can hold some<br>
> data. It would look like that:<br>
> <br>
> resources:<br>
> is_prod:<br>
> type: OS::Heat::Value<br>
> properties:<br>
> value: {equals: {get_param, env}, prod}}<br>
> <br>
> my_resource:<br>
> condition: {get_attr: [is_prod, value}}<br>
<br>
Another alternative (which maybe you discussed, sorry I missed the IRC<br>
chat) would be just to use parameters, as that's already conceptually where<br>
we obtain values that are input to resources.<br>
<br>
E.g:<br>
<br>
parameters:<br>
env:<br>
type: string<br>
default: prod<br>
<br>
is_prod:<br>
type: boolean<br>
default: {equals: {get_param, env}}<br>
<br>
>From an interface standpoint this seems much cleaner and more intuitive than<br>
the other solutions discussed IMHO, but I suspect it's potentially harder to<br>
implement.<br>
<br>
Your original example gets much cleaner too if we allow all intrinsic function<br>
(except get_attr) in the scope of parameters:<br>
<br>
parameters:<br>
host:<br>
type: string<br>
port:<br>
type: string<br>
endpoint:<br>
type: string<br>
default:<br>
str_replace:<br>
template:<br>
<a href="http://HOSTORT/">http://HOSTORT/</a><br>
params:<br>
HOST: {get_param: host}<br>
PORT: {get_param: port}<br>
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>