On 09/23/2015 02:17 AM, 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 implementation in pastebin above. Much better solution than
running function.
Regards,
Martin
__________________________________________________________________________
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
