Hi,
I'm trimming the discussion because I plan to answer on the language
part later when I'll have more time.
>>>>> 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.
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.
>>>>> 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.
> 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.
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).
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?
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.
--
Brice Figureau
Days of Wonder
http://www.daysofwonder.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
-~----------~----~----~----~------~----~------~--~---
