[openstack-dev] [puppet] service default value functions

Matt Fischer matt at mattfischer.com
Thu Sep 17 17:58:50 UTC 2015


Clint,

We're solving a different issue. Before anytime someone added an option we
had this logic:

if $setting {
  project_config/setting: value => $setting
}
else {
  project_config/setting: ensure => absent;
}

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.

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.



On Thu, Sep 17, 2015 at 11:39 AM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Alex Schultz's message of 2015-09-16 09:53:10 -0700:
> > 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?
>
> I'm confused.
>
> Why aren't you omitting the configuration option from the file if you
> want to use the default? Isn't that what undef is for?
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/8325565b/attachment.html>


More information about the OpenStack-dev mailing list