<div dir="ltr">Clint,<div><br></div><div>We're solving a different issue. Before anytime someone added an option we had this logic:</div><div><br></div><div>if $setting {</div><div>  project_config/setting: value => $setting</div><div>}</div><div>else { </div><div>  project_config/setting: ensure => absent;</div><div>}</div><div><br></div><div>This was annoying to have to write for every single setting but without it, nobody could remove settings that they didn't want and fall back to the project defaults. </div><div><br></div><div>This discussion is about a way in the libraries to do the ensure absent but to drop all the else {} clauses in all our modules.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 11:39 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Alex Schultz's message of 2015-09-16 09:53:10 -0700:<br>
<span class="">> Hey puppet folks,<br>
><br>
> Based on the meeting yesterday[0], I had proposed creating a parser<br>
> function called is_service_default[1] to validate if a variable matched our<br>
> agreed upon value of '<SERVICE DEFAULT>'.  This got me thinking about how<br>
> can we maybe not use the arbitrary string throughout the puppet that can<br>
> not easily be validated.  So I tested creating another puppet function<br>
> named service_default[2] to replace the use of '<SERVICE DEFAULT>'<br>
> throughout all the puppet modules.  My tests seemed to indicate that you<br>
> can use a parser function as parameter default for classes.<br>
><br>
> I wanted to send a note to gather comments around the second function.<br>
> When we originally discussed what to use to designate for a service's<br>
> default configuration, I really didn't like using an arbitrary string since<br>
> it's hard to parse and validate. I think leveraging a function might be<br>
> better since it is something that can be validated via tests and a syntax<br>
> checker.  Thoughts?<br>
<br>
</span>I'm confused.<br>
<br>
Why aren't you omitting the configuration option from the file if you<br>
want to use the default? Isn't that what undef is for?<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>