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