On 2013-07-10 19:57, Ashley Penney wrote:
Hi guys,
As I mentioned in a previous email I've refactored ntp and released a
1.0.0 release candidate. There's one outstanding "flaw" remaining that's
bothering me and I wanted to solicit opinions on the list. We currently
maintain a template per distribution that is close to the stock
distribution provided ntp configuration. This leads to massive sprawl
and means adding a distribution means yet another template.
Would users of the ntp module mind if we unified this all into a single
template? Obviously we'd have to pick one as the best "base" template
and move over to using it and deal with the fact that your ntp
configuration would significantly change.
Only a few days ago I would have objected vehemently against such a
change. I came to realize that in the puppet vision, distribution
specific differences matter less and less. In a way any set of puppet
modules becomes its own distribution, its configuration specified by
class inclusion and resource usage.
Accepting that, the question of differences to the distribution provided
conffile ceases to be of relevance.
The important questions become - as demonstrated in another part of this
thread - questions of operation and best practices. Some of those - like
how to react on is_virtual - can perhaps be answered with defaults,
others like the cron-vs-daemon debate have underlying tradeoffs which
have to be documented and made configurable. This is where the puppet
module can excel, as it can wildly reconfigure the system in reaction to
a top-level decision.
The question arises what can be done to upstream such policies. I would
expect[1] package maintainers to have a high interest in flexibly
providing the experience for their users. In Debian - where I have the
most experience - the reality is that maintainers do not have wide
latitude in reconfiguring systems, since the expectation is - rightly -
that user's changes are preserved and packages should not try to
configure each other. Judging from the things I've seen in RedHat-land,
RPMs have even less structure and authority.
The alternative seems to be to both throw away much that is provided by
distributions to achieve a least common denominator and (re-)implement
much that is required for features. Following this line of thought, I
soon come to see the parallels to the development of ruby, where a
complete set of alternative implementations of basic tools has happened.
rbenv/rvm/bundler/gem/rpmforge/passenger/unicorn re-implement the whole
stack from container[chroot|lxc]/package manager[dpkg|rpm]/web
application host[apache] again, only a few layers[1] further up. Looking
at the work on Fedora's Software Collections, we've already come full
circle once: e.g. The Foreman deploys a complete ruby stack via yum to
/opt on EL6 (and co.), including a custom set of puppet modules, called
the foreman-installer. On the other hand, projects like icinga don't
even manage (or care) to provide current binary releases.
I'm wondering how that will play out in the next few years.
[1]http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints
Obviously we'd still be using your custom servers in the template so
that bit wouldn't change. We could expand the "restrict" option to let
you pass in more customized options here. What else would people like to
be able to tune, change, tinker, trigger, whack, or modify in terms of
parameters? If you have a really complex ntp setup then I want to hear
from you! The more complex and awkward the better so that we can be sure
our module meets your needs.
While a common set of top-level options is nice for things like servers
or runmode, the quirky configurations might be easier solved by just
passing in a replacement template.
It might be interesting though, to support some kind of (semi-)automatic
keying to support encrypted/signed communications, something that is
conspicuously absent from all default configs I know.
Regards, David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
