On Sep 16, 2010, at 11:29 PM, Nigel Kersten wrote:
> 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... :)
Huh, I thought we could.
> 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.
So either entirely or essentially global defaults?
> We have an apt::update class that all packages are set to require, and
> that all repositories are set to be before.
This kind of thing would be well-supported by the ability to do something like
include defaults (and maybe variables) from one class into another - akin to
including a Module in ruby. E.g., with this setup:
class apt {
Package { provider => apt }
}
class main {
extend_with apt
}
That would take all of the defaults and add them to main, as though they were
defined in main directly.
Would that provide sufficient equivalent functionality?
> 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.
Do you find this to be a sufficient, or even better, replacement, or do you
just use it because you figure it's more supported?
>> 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.
But that's only because you're used to looking in that file, right? Because
shouldn't it generally be easier to see everything in a nice, clean GUI than
that ugly text file? :)
> 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.
My plan here is to support what we're obligated to call Smart Groups in the
Dashboard - group hosts by fact values, and then allow you to attach class
membership and parameters to those groups. E.g., in your example, you'd have a
smart group named 'Engineering Laptops' based on a query for all hosts whose
owner_org=engineering and hardware_class=laptop, and you'd add the
'engineering::laptop' class to it.
Yes, this would be in the dashboard, not the code, but I think that would end
up being more maintainable in the long run, especially since you could actually
quickly see who was actually in that group, which I expect you cannot do now.
> 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]
Why can't the classifier be part of that process?
> 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...
Hmm.
--
If two men agree on everything, you may be sure that one of them is
doing the thinking. -- Lyndon B. Johnson
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
