Open Stack

On 09/22/2015 08:17 PM, Cody Herriges wrote:
> 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?
>>
>>
>> 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
>>
> 
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "<SERVICE DEFAULT>" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
> 
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
> 
> http://paste.openstack.org/show/473655

+1 for this solution, which is straightforward and easy to
maintain/implement.
-1 for a fact which is (to me) more code and relying on puppet versions
is something a bit dangerous, even if facts.d are supported by our CI jobs.
-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150923/7ced0912/attachment.pgp>