On Wednesday, January 30, 2013 9:41:31 PM UTC, Ti Leggett wrote:
>
> On Jan 30, 2013, at 2:33 PM, jcbollinger wrote:
>
> >> not mash all the public bits in to one globally public class that has
> no nitty gritty bits to implement. In my example <module>::params is
> considered the header for the module (granted a header that exposes values,
> but that can't be helped due to the declarative nature of the DSL). There
> should be no implementation in that sub-module and even <module> should
> reference that 'header' to get the variables it needs to do its work. But
> I'll still pay penance at the OO altar for all my past transgressions
> against and abuses of it.
> >>
> >
> >
> > Maybe we're just having a terminology problem. Puppet has no concept of
> sub-modules, and the only construct available to hold reference-able,
> non-global variables is the class. Indeed, even modules themselves are a
> Puppet implementation detail -- the DSL has no concept of them except as
> top-level namespaces (but top-level namespaces often map to classes, either
> instead of or in addition to mapping to modules).
> >
> > So, would you care to explain how your <module>::params then differs
> from "mash[ing] all the public bits in to one globally public class that
> has no nitty gritty bits to implement"? Are you suggesting separate
> ::params classes shadowing multiple different classes in the same module?
> Are you conflating class parameters with class variables?
> >
>
> Let's go back to my original example from http://pastie.org/5910079#. Not
> stated in that code snip (for conciseness) is a module, kibana. Among other
> things it needs to install an apache configuration to make it a useful
> piece of software and that configuration is in the kibana::apache sub-class
> in the form of a snippet that is tagged such that the apache module can
> instantiate it later on at the proper time (there's an alternative to this
> method). In order to do this, the kibana::apache class needs to know where
> to install this configuration file so that the apache process can load it.
> That location I chose to place in a variable, $config_d, in the apache
> module in a sub-class (sorry for the improper nomenclature before)
> apache::params. To solve my original problem I simply add:
>
> include 'apache::params'
>
For this specific example I would not model it this way. I would make the
Apache module provide an interface to allow other modules to add to itself.
I would make something like an 'apache::vhost' or
'apache::extra_conf_file', which is just a wrapper around a Puppet File and
a notify => Service[]. Thus the implementation of how to create/manage
Apache config files (like their location) is wholly contained in the Apache
module and other modules don't have to "know" specific details.
That design may not scale out for more complex examples though. Looking at
my own modules I should really practice what I preach because all too often
I just drop a file in /etc/httpd/conf.d from anywhere I please ;-)
right above the @file snippet in kibana::apache and everything is happy. I
> think everyone can agree that is the right solution to the problem that I
> posed; however, both you and Luke strongly suggested against having modules
> include other module's variables willy nilly and instead move those
> variables that multiple modules need to reference into a globally included
> class, we'll call it globals::. This class, I assume (correct me if I
> assume wrong), would always be instantiated before all others, say in the
> nodes.pp file, to ensure that all subsequent modules could resolve the
> variable appropriately. I would assume in that class you would have all of
> these 'global' variables that multiple modules make use of so you'd have
> (eventually) a long list in this one class:
>
> class globals {
> $apache_config_d = '/etc/httpd/conf.d'
> $openldap_schema_d = '/etc/openldap/schemas'
> $rsyslog_d = '/etc/rsyslog.d'
> $ssl_ca_path = '/etc/pki/tls/certs'
> ...
> }
>
> And in my kibana::apache class I would reference
> ${globals::apache_config_d}. If all of those assumptions are true, I'm
> curious why this solution is any better? The only benefit that I can see is
> that when writing a new module you don't trouble making sure you've loaded
> the proper prerequisites for variable resolution because it should already
> be done. You're still including another classes variables, albeit in this
> only ever one other class. The other alternative that has been alluded to
> in a pure programmatic way is that none of those variables should be shared
> between modules and each module should have their own local variable to
> use. I'll consider this proposed as only for the purist and not really
> tractable in any real complex environment.
>
> What I proposed is only semantically different than the above but, in my
> mind, is a cleaner (you don't have one huge file that has all variables)
> and more explicit (you are required to include the class that has the
> variable you care about when writing your module). It leaves the variables
> closest to the module that has the most influence over that variable - the
> variable $ssl_ca_path is directly dictated by the openssl package (which
> can only be in one module) and so it should remain as close to the module
> that contains that package.
>
> As another tangent, I mentioned there was an alternative to having the
> kibana apache configuration be served from kibana module and that is to
> move the kibana config into the apache module. That would solve the
> cross-module variable referencing, but again, in my head that removes the
> element further from the thing that most influences it - the kibana apache
> configuration certainly requires and makes use of the apache module, but
> the kibana module has more influence over the kibana apache configuration
> itself.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
