On Nov 25, 2008, at 3:19 AM, Brice Figureau wrote:
>
> On Tue, 2008-11-25 at 00:39 -0600, Luke Kanies wrote:
>> On Nov 24, 2008, at 3:57 PM, Brice Figureau wrote:
>>>> Luke:
>>>> Would we similarly consider it an error if we had an override
>>>> with a
>>>> collection that didn't match any resources? That is, say we had
>>>> this:
>>>
>>> The thing is that I'm adding override (at least in the current patch
>>> incarnation which also collect current catalog resource) when we
>>> actually collect something, so this situation can not happen.
>>>
>>> That means you can do:
>>>
>>> @file {}
>>> Package <| |> { require => Something["else"] }
>>>
>>> And it does nothing.
>>
>> Is the '@file {}' syntax in the current patch?
>
> No, it was just an abbreviation of
> @file { "title": content => "" }
>
> but I was too lazy to actually make it parse right :-(
*whew*
>
>> I know we discussed
>> it, but what does it do? Is it necessary to add that syntax for the
>> override/collect syntax? If not, I'd prefer to delay it.
>
> No, no, parse error on my side.
>
> I was just trying to say: look I'm collecting package with override
> but
> there are none defined and I don't get any issue in
> fail_on_unevaluated_overrides.
Okay, that works for me.
>>>> File[tag == apache] { ensure => absent }
>>>>
>>>> If there aren't any file resources tagged apache, would this
>>>> throw an
>>>> exception?
>>>>
>>>> I think it shouldn't since we should pretty clearly support empty
>>>> sets, but it certainly makes things different.
>>>>
>>>> Empty sets bring up the 'require' stuff above, too -- we'd need to
>>>> handle, in the RAL, empty arrays for all those cases where we would
>>>> expect arrays of resource references, because there would always be
>>>> times where the collection would not match any resources.
>>>
>>> The only issue about "global" override is the following:
>>>
>>> file {
>>> "/tmp/a": content => "a"
>>> }
>>>
>>> file {
>>> "/tmp/b": content => "b"
>>> }
>>>
>>> File <||> { require => File["/tmp/a"] }
>>>
>>> And of course this fails with a recursion on the first file.
>>> That can be easy to solve, by just modifying the override stuff to
>>> not
>>> allow overriding parameters containing resource references for the
>>> currently overriden resource.
>>
>> If it's too complicated to fix this, I wouldn't worry about it too
>> much -- I guess it can happen, but this seems like a bit of a silly
>> problem to have and it's fine not supporting it out of the gate.
>
> I don't think it is difficult to solve.
> And it can well be workarounded with:
>
> File <| title != "/tmp/a" |> { require => File["/tmp/a"] }
Hmm, that's simple enough I'm happy to actually not have builtin
support for avoiding the problem. Seems people should be aware when
they're doing self-referencing relationships, shouldn't they? Maybe
I'm asking too much...
>>> Also, I'm sure what people want to do is in the end something like
>>> this:
>>>
>>> Package { require => Yumrepo[sth] }
>>>
>>> The thing is that the current version acts as an override so if you
>>> have
>>> somewhere else:
>>>
>>> package { "postfix": ensure => isntalled, require =>
>>> File["responsefile"] }
>>>
>>> I think I'm loosing the require on the responsefile (I didn't test
>>> it,
>>> though).
>>
>> This is a default, not an override, and for it, you'd lose the
>> yumrepo, not the responsefile -- defaults get ignored if the param is
>> set.
>
> In fact I didn't meant what I wrote, I meant what people want to do
> usually but which is not possible at that time, that is have a global
> require for a "class" of entities (ie all packages should require the
> setup of a yumrepo first, or all packages should require an apt-get
> update before...).
Ah.
>
>> For overrides, though, relationship params stack, so you'd get both.
>
> Cool, I thought it was overwriting parameters, including relationship
> params.
Used to, hasn't since about 0.24.2 or so.
>
>>> I'm still not sure about why the override should only be in
>>> inherited
>>> scope, especially now that I'm also collecting non-virtual resouces.
>>> Can
>>> you think of an example that'd fail in non inherited scope?
>>
>> Well, it would just allow any part of your configuration to modify
>> any
>> other part of your configuration, which would get very messy very
>> quickly. Crucially, the load order would determine what overrides
>> won. Take this class structure:
>>
>> class base {
>> file { "/a": }
>> }
>> class s1 {
>> File["/a"] { owner => root }
>> }
>> class other {
>> File["/a"] { owner => adm }
>> }
>>
>> If you don't use inheritance, then the value of 'owner' is determined
>> by the last class that gets evaluated. If you do use inheritance,
>> then you always know the winner.
>
> OK, got it.
> So I have to make sure we can collect and override only in a subscope?
The collection doesn't matter so much as the override, and we
established before that the overrides will retain their behaviour, so
your patch keeps the behaviour with no problem.
>
> I don't think I have a clear vision of what would be the usage pattern
> of the collect+override stuff, especially in inherited context.
>
> What I'm sure, is that people will want to do at the top of their site
> manifest or in their yum modules (or anything like that):
> Package <| |> { require => Yumrepo["repo"] }
>
> I want to be sure that's possible with the current patch.
Hrm. That won't be possible with this patch, I'm nearly sure, unless
every class has a heirarchical relationship with the class defining
that override.
This brings up something a bit fundamental, and I'm not sure it can be
solved in this patch. The problem sits somewhere between the
difference between an override and a default, and the difference
between scope behaviour in class heirarchies and scope heirarchies
determined by class evaluation.
Essentially, we've got parameter settings and scope heirarchies that
flow downward (defaults and class evaluation) and upward (overrides
and class heirarchies).
For example, if you have a resource default defined in the site.pp
file, outside of any node or class definitions (meaning it's defined
in the top scope), then all other scopes will inherit that default
because (like variables) defaults are sought upward in the heirarchy,
meaning their area of affect is downward.
Overrides, on the other hand (as implemented now), work upward -- you
define a given resource in a scope, and only subscopes can change that
resource. (While it might look like this collect/override could have
a downward area of affect, it can't, because of the rules on how
overrides work.)
So, you could conceivably have a single resource, defined in a scope
between two scopes, where the top scope defines a default and the
bottom scope defines an override, and both of those statements could
affect the resource. In quite-possibly strange ways.
It's seeming more and more like defaults and overrides are nearly the
same thing, and maybe we could unify them in some way, and at the same
time unify the scope search issues.
This is related to one of David Lutterkort's initial issues with
Puppet -- it's dynamically scoped rather than static, meaning that as
you evaluate classes their scopes are attached in the heirarchy at the
evaluation point, rather than at the definition point, such that
variable search (and thus, default search) goes through the evaluating
scope.
It might be that we can come up with a single world view that treats
class heirarchies, dynamic scoping, variable lookup, defaults, and
overrides in a consistent and more maintainable way, and it's long
past time we came up with such a view. I'm skeptical we could do so
in a backward compatible way, though. Seems I've got some caffeine-
fueled pondering to do.
Anyone have any ideas?
--
The Internet, of course, is more than just a place to find pictures of
people having sex with dogs. -- Time Magazine, 3 July 1995
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
