On Nov 24, 2008, at 3:57 PM, Brice Figureau wrote:
>
> Hi,
>
> I'm trimming the discussion because I plan to answer on the language
> part later when I'll have more time.
Cool.
>
>>>>>> Luke wrote:
>>>>>> Barring any brilliant ideas from others, I'd say just provide the
>>>>>> behaviour change described above (the local resource query
>>>>>> operates
>>>>>> against all resources, and marks virtual resources as non-
>>>>>> virtual).
>
>>>>> Brice wrote:
>>>>> OK, so instead of acting only on virtual resources, we scan both
>>>>> virtual
>>>>> resources and catalog resources, select them, override them
>>>>> accordingly
>>>>> and if we ever encounter one that is virtual, we realize it.
>>>>> Is it right?
>
> I did the aforementionned change and it seems to work fine.
> This is a small addition to my current patch for 1088.
Sounds good.
>
> I didn't started working on the syntax change yet, I'm not sure we
> finally agreed on something. That'll be the subject of another e-mail
> quoting the previous part of the discussion.
Ok.
>
>>>>>> Note that the evaluate_generators method in Parser::Compiler
>>>>>> should
>>>>>> be
>>>>>> evaluated to make sure its behaviour still makes sense with this
>>>>>> change, along with the 'fail_on_unevaluated' method in the same
>>>>>> class.
>>>>> I'll try to assess this later this week. But I think
>>>>> evaluate_generators
>>>>> will still be used by storeconfigs resources, right?
>>>> Every collection would be evaluated in the evaluate_generators
>>>> method,
>>>> and any overrides would need to end up in the fail_on_unevaluated
>>>> method (although I'm not exactly sure if it's even necessary for
>>>> overrides related to collections -- I suppose the overrides would
>>>> happen when the collections are evaluated).
>>> I don't think it matters, in the end the resources get overriden in
>>> Compiler.finish(). I'm not sure that moving the overriding
>>> directly in
>>> evaluate_collections (or evaluate_generators) brings us any
>>> advantage.
>>> Or maybe I'm wrong and I don't see your point?
>>
>>
>> The point is that right now, overrides are per-resource: If you
>> specify an override, Puppet considers it an error if that resource
>> was
>> not found and thus the override was not applied.
>
> That's right.
>
>> 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? 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.
>
>> 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.
>
> 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.
For overrides, though, relationship params stack, so you'd get both.
>
> 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.
>
> Now, we (you Luke in fact) only have to define the syntax if you think
> it is still necessary to change it in favor of something different.
>
> I'll publish the branch soon (needs more testing, more tests, and a
> few
> code) if someone wants to throw an eye on it.
I'm good with the simple change to start with, and we'll look at the
more complicated stuff later.
--
Work is not always required. There is such a thing as sacred idleness.
-- George MacDonald
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
