Re: [openstack-dev] [Heat] Re-evaluate conditions specification

2016-03-31 Thread Fox, Kevin M 
My initial reaction is that sounds good, but how is it different then params, 
or maybe a hidden param? Maybe they are conditionally assigned? Conditional 
params would be awesome too though. If param 1 is not set, then param 2 is 
required...

Thanks,
Kevin


From: Thomas Herve
Sent: Thursday, March 31, 2016 1:40:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Heat] Re-evaluate conditions specification

Hi all,

As the patches for conditions support are incoming, I've found
something in the code (and the spec) I'm not really happy with. We're
creating a new top-level section in the template called "conditions"
which holds names that can be reused for conditionally creating
resource.

While it's fine and maps to what AWS does, I think it's a bit
short-sighted and limited. What I have suggested in the past is to
have a "variables" (or whatever you want to call it) section, where
one can declare names and values. Then we can add an intrinsic
function to retrieve data from there, and use that for examples for
conditions.

It solves that particular issue, and it opens some interesting
possibilities for reducing duplication in the template, as we could
build arbitrary values out of parameters or attributes that can then
be reused several times.

Thoughts?

--
Thomas

__
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
__
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

Re: [openstack-dev] [Heat] Re-evaluate conditions specification

2016-03-31 Thread Thomas Herve 
On Thu, Mar 31, 2016 at 11:39 AM, Qiming Teng
 wrote:
> On Thu, Mar 31, 2016 at 10:40:33AM +0200, Thomas Herve wrote:
>> Hi all,
>>
>> As the patches for conditions support are incoming, I've found
>> something in the code (and the spec) I'm not really happy with. We're
>> creating a new top-level section in the template called "conditions"
>> which holds names that can be reused for conditionally creating
>> resource.
>>
>> While it's fine and maps to what AWS does, I think it's a bit
>> short-sighted and limited. What I have suggested in the past is to
>> have a "variables" (or whatever you want to call it) section, where
>> one can declare names and values. Then we can add an intrinsic
>> function to retrieve data from there, and use that for examples for
>> conditions.
>>
>> It solves that particular issue, and it opens some interesting
>> possibilities for reducing duplication in the template, as we could
>> build arbitrary values out of parameters or attributes that can then
>> be reused several times.
>>
>> Thoughts?
>
> Though not very excited by the current approach, I'm still a little bit
> concerned about the extent to which we are extending the 'conditionals'
> support. This is not an easy call given that we don't want HOT to become
> a programming language.
>
> A long time ago, we have a proposal from sdake. That one was stagnated
> for ever. If we want to revisit this topic from step 0, we may as well
> need to define the scope cleanly. For example, are we gonna support some
> idioms for 'if, elif' only or we are introducing 'switch/case' also?
> Are we introducing a boolean evaluator that can be applied to all data
> types so that we get grammar completeness?
> Are we gonna support logical operators as well? e.g. AND, OR, NOT?
> Would this mean we are introducing some "reserved words" to HOT, or some
> more builtin functions?
> If these are to be modeled as functions, do we still want them to be
> implemented at client side, as we do for 'get_file'?

That's an interesting conversation, but not the one I was expecting to
trigger. I believe
http://specs.openstack.org/openstack/heat-specs/specs/mitaka/support-conditions.html
answers most of the questions you're asking. I mostly try to adjust
one point of that spec already approved.

-- 
Thomas

__
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

Re: [openstack-dev] [Heat] Re-evaluate conditions specification

2016-03-31 Thread Thomas Herve 
On Thu, Mar 31, 2016 at 10:40 AM, Thomas Herve  wrote:
> Hi all,
>
> As the patches for conditions support are incoming, I've found
> something in the code (and the spec) I'm not really happy with. We're
> creating a new top-level section in the template called "conditions"
> which holds names that can be reused for conditionally creating
> resource.
>
> While it's fine and maps to what AWS does, I think it's a bit
> short-sighted and limited. What I have suggested in the past is to
> have a "variables" (or whatever you want to call it) section, where
> one can declare names and values. Then we can add an intrinsic
> function to retrieve data from there, and use that for examples for
> conditions.

I was asked to give examples, here's at least one that can illustrate
what I meant:

parameters:
   host:
  type: string
   port:
  type: string

variables:
   endpoint:
  str_replace:
template:
   http://HOST:PORT/
params:
   HOST: {get_param: host}
   PORT: {get_param: port}

resources:
   config1:
  type: OS::Heat::StructuredConfig
  properties:
config:
   hosts: [{get_variable: endpoint}]

-- 
Thomas

__
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

Re: [openstack-dev] [Heat] Re-evaluate conditions specification

2016-03-31 Thread Qiming Teng 
On Thu, Mar 31, 2016 at 10:40:33AM +0200, Thomas Herve wrote:
> Hi all,
> 
> As the patches for conditions support are incoming, I've found
> something in the code (and the spec) I'm not really happy with. We're
> creating a new top-level section in the template called "conditions"
> which holds names that can be reused for conditionally creating
> resource.
> 
> While it's fine and maps to what AWS does, I think it's a bit
> short-sighted and limited. What I have suggested in the past is to
> have a "variables" (or whatever you want to call it) section, where
> one can declare names and values. Then we can add an intrinsic
> function to retrieve data from there, and use that for examples for
> conditions.
> 
> It solves that particular issue, and it opens some interesting
> possibilities for reducing duplication in the template, as we could
> build arbitrary values out of parameters or attributes that can then
> be reused several times.
> 
> Thoughts?

Though not very excited by the current approach, I'm still a little bit
concerned about the extent to which we are extending the 'conditionals'
support. This is not an easy call given that we don't want HOT to become
a programming language.

A long time ago, we have a proposal from sdake. That one was stagnated
for ever. If we want to revisit this topic from step 0, we may as well
need to define the scope cleanly. For example, are we gonna support some
idioms for 'if, elif' only or we are introducing 'switch/case' also?
Are we introducing a boolean evaluator that can be applied to all data
types so that we get grammar completeness?
Are we gonna support logical operators as well? e.g. AND, OR, NOT?
Would this mean we are introducing some "reserved words" to HOT, or some
more builtin functions?
If these are to be modeled as functions, do we still want them to be
implemented at client side, as we do for 'get_file'?

Regards,
  Qiming
 
> -- 
> Thomas
> 
> __
> 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
> 


__
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

[openstack-dev] [Heat] Re-evaluate conditions specification

2016-03-31 Thread Thomas Herve 
Hi all,

As the patches for conditions support are incoming, I've found
something in the code (and the spec) I'm not really happy with. We're
creating a new top-level section in the template called "conditions"
which holds names that can be reused for conditionally creating
resource.

While it's fine and maps to what AWS does, I think it's a bit
short-sighted and limited. What I have suggested in the past is to
have a "variables" (or whatever you want to call it) section, where
one can declare names and values. Then we can add an intrinsic
function to retrieve data from there, and use that for examples for
conditions.

It solves that particular issue, and it opens some interesting
possibilities for reducing duplication in the template, as we could
build arbitrary values out of parameters or attributes that can then
be reused several times.

Thoughts?

-- 
Thomas

__
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