On Thu, Sep 16, 2010 at 7:02 PM, Luke Kanies <[email protected]> wrote:
> On Sep 16, 2010, at 9:48 PM, Nigel Kersten wrote:
>>>> So the plan is that the only place you can reliably set global
>>>> resource defaults is directly in your site.pp or in an *import* from
>>>> site.pp ?
>>>
>>> It's more of a hope than a plan at this point, but really, every variable
>>> is functionally global, in that you can refer to it from anywhere else
>>> using the scoping syntax.
>>
>> Sure, but this model doesn't hold for resource defaults :)
>
> True dat. Sorry, I somehow missed that specified resource defaults.
>
> How do you use them now? And if you can provide a bit of depth, I'd
> appreciate it - that is, how deep the class structures go, whether classes
> set defaults for orthogonal classes (e.g., security for web), and especially
> whether you have orthogonal, non-global defaults (e.g., defaults that apply
> non-globally but to more than one portion of your class heirarchy).
We would use them even more if you could easily append to resource
defaults... :)
We use them to essentially set up global before/require relationships
between resources and classes, and to set providers for resource types
where there either isn't a default or the default isn't what we want.
We have an apt::update class that all packages are set to require, and
that all repositories are set to be before.
We used to make heavy use of the inherited scope for resource
defaults, but partly due to maintenance issues and partly due to
seeing the writing on the wall on the dev list, we've started using
defined types instead.
ie rather than a simple file and exec, both with resource defaults, we
instead make a defined type to abstract them both away. We should
probably have been doing this in the first place.
>
> I've got some ideas for how this might work, including adding a kind of 'add
> defaults from class A to my class' behaviour, but they're very nebulous.
>
>>>> and thus not inside a class that may include all your other classes?
>>>> (we have a module 'base' that does all the logic for which other
>>>> classes should be included)
>>>
>>> This can be pretty easily done using fully qualified variables, but it's
>>> even better done using extlookup or equivalent.
>>
>> I disagree pretty strongly that extlookup is better for this specific
>> purpose, even acknowledging how fully qualified variables let you
>> achieve this under the proposed model, and that separating data from
>> models is generally awesome.
>
> I'd like to hear more about this.
It really just comes down to maintainable code that is quickly
understandable. It's much simpler to look in "class base" for the
logic as to what other modules are being included than it is to bury
this data away in extlookup or to put it in the external node
classifier.
As we have a large and rapidly changing client base, it's easier to
make them self-organizing, with facts that report back certain info
like:
* am I a laptop? desktop? server?
* am I in a DMZ?
* what sub-org does my owner belong to?
etc etc
and then we make use of those facts to work out what modules should be
imported. This is pretty easily understandable for anyone coming to
the code base for the first time, as they look in base and see
something like:
if $owner_org == "engineering" and $hardware_class == "laptop" {
include engineering::laptop
}
That looks (and is) a touch contrived, but we don't necessarily have a
class for every $owner_org, so include $owner_org::$hardware_class
isn't the right solution.
We may also allow in some environments for users to touch data on
their local machine that is reported back by a fact to enable/disable
large chunks of functionality. We use this a lot for people to opt
into pre-release testing.
if $deathray == "sure" { include projects::deathray }
as we can actually test the delivery of the functionality via puppet
without everyone necessarily getting it, and you don't want to have to
explicitly configure this on a per-machine basis.
It can be argued that a well laid out external classifier can do this
job, but we use environments for our release process, obviously the
classifier can't be part of that process, and we have different teams
responsible for the classifier (which is part of our puppet
infrastructure) and the actual manifests, which are managed by the
different platform teams.[1] and [2]
I just don't really see how extlookup really solves this problem
better, even though it's awesome for many other problems.
Nigel
[1] - We have our configurations divided into two main sections.
"core" and "addons". To include "core", all the classifier needs to do
is to include the "base" module, and then it looks up our external
node definitions for the addon modules that service owners have
specified should be applied to their hosts.
[2] - I still have this pipe dream that we could do away with
environments altogether *if* the external node classifier could set
the modulepath and manifestpath.... Can you imagine how cool and
flexible that would be? It would be trivial to solve the problem of
staged release processes this way...
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
