Open Stack

On 09/16/2015 09:39 PM, Emilien Macchi wrote:
>
> On 09/16/2015 12:53 PM, Alex Schultz wrote:
>> Hey puppet folks,
>>
>> Based on the meeting yesterday[0], I had proposed creating a parser
>> function called is_service_default[1] to validate if a variable matched
>> our agreed upon value of '<SERVICE DEFAULT>'.  This got me thinking
>> about how can we maybe not use the arbitrary string throughout the
>> puppet that can not easily be validated.  So I tested creating another
>> puppet function named service_default[2] to replace the use of '<SERVICE
>> DEFAULT>' throughout all the puppet modules.  My tests seemed to
>> indicate that you can use a parser function as parameter default for
>> classes. 
>>
>> I wanted to send a note to gather comments around the second function. 
>> When we originally discussed what to use to designate for a service's
>> default configuration, I really didn't like using an arbitrary string
>> since it's hard to parse and validate. I think leveraging a function
>> might be better since it is something that can be validated via tests
>> and a syntax checker.  Thoughts?
> Let me add your attempt to make it work in puppet-cinder:
> https://review.openstack.org/#/c/224277
>
> I like the proposal, +1.
Alex, thank you for this proposal.

I like your approach :

 * as it will make writing manifest more idiomatic.

$foo = service_default() with if is_service_default($foo) { } reads
better than
$foo = '<SERVICE DEFAULT>' with if $foo == '<SERVICE DEFAULT>'.

 * if for any reason, hopefully this shouldn't happen but we need to
change the value,
it will happen only on few places. (less commit to review)

 * the end result is the exact same one as the one we have today.

For me it's a go, let's see what the other have to say about it

Thank you,

>
>> Thanks,
>> -Alex
>>
>> [0] http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
>> [1] https://review.openstack.org/#/c/223672
>> [2] https://review.openstack.org/#/c/224187
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev