Unfortunately, we have many dozen modules and hundreds of classes, with a
disjoint set of people using and maintaining them. What you suggest simply
isn't practical. :-( Asking the human element to keep track of what
relevant changes have been made, and alter scripts accordingly, is not only
is in the
catalogue before it declares a dependency relationship.
defined() doesn't cut it, since the class in question may not
have been scanned yet.
If it's collect **then** connect, I'll be adding a FREQ for
a function (or other means) to access/check the collection
prior to the connexion phase..
--
Ken Coar
On Monday, May 6, 2013 3:36:06 PM UTC-4, Gerardo Santana Gómez Garrido
wrote:
Hi Ken,
I'm not sure I fully understood the purpose of each class, and until then
I'm not pointing out issues. But if my interpretation is correct then you
may get something useful from this other pattern:
#
On Monday, May 6, 2013 9:22:36 PM UTC-4, Ygor wrote:
This looks great.
Mine, or Gerardo's?
Some constructive criticism:
I think “defaults and “settings” are redundant.
Use one.
Actually, though, IMHO they're not. 'Defaults' are what you get if they
aren't overridden. 'Settings' are
On Tuesday, May 7, 2013 12:02:11 AM UTC-4, Wolf Noble wrote:
I'm happy to give my $.02, FWIW.
I've found immense benefit from the overall paradigm described in Craig
Dunn's blog post here:
http://www.craigdunn.org/2012/05/239/
I'll check it out in light of your comments. Thanks!
--
On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote:
I think there's a great advantage to using a consistent module structure,
whatever that happens to be.
D'accord! Hence this attempt.
1. mod::defaults (defaults.pp)
- does *not* inherit from anywhere
-
I've been having to write (and modify) a lot of modules lately, and I've so
far moved to the following pattern. I'd appreciate comments and feedback
about my approach, particularly in light of the changes to name scoping
(all my modules are currently deployed under 2.7).
1. mod::defaults
On Monday, April 22, 2013 9:48:21 AM UTC-4, jcbollinger wrote:
Well, no. The Puppet agent does not function as a file server, so you're
not proposing to make use of anything that's already there. And, even if
the agent could provide file services, you're still talking about setting
up
On Thursday, May 2, 2013 6:37:00 PM UTC-4, jcbollinger wrote:
Although the 'file server' item is under the 'Shared master agent API'
section in that it comes later in the document, it is *part of* the next
section, 'The master HTTP
On Friday, April 19, 2013 5:46:37 AM UTC-4, David Schmitt wrote:
Is there any reason to use a puppet as source? You can put that on an
NFS share too and reference it by path. Or clone a git repo.
Simplicity. Keeping everything in the puppet milieu, which is already
set up. Don't want to
Background:
The puppetmasters are under the authority and control of a specific group
(not mine ;-) ). Client sysadmins have control over the node manifests
and, to a certain extent, can modify the puppet modules.
One of the modules (and potentially others) used by my group uses a lot
of files
ARAIK, we haven't had to do that for anything except parameters from the
node manifest, and we haven't completely finished doing that.
Isn't this covered somewhere in the 'death of dynamic scoping'
discussions/documentation?
#k
--
You received this message because you are subscribed to the
12 matches
Mail list logo
