On Wed, 2008-10-15 at 09:10 +0200, David Schmitt wrote:
> Luke Kanies schrieb:
> >>> I assume these overrides follow the same rules as current overrides
> >>> --
> >>> only possible within a subclass?
> >> Maybe I'm plain wrong, but I don't think this restriction is
> >> necessary,
> >> since after all if the original resource is not collected/realized it
> >> doesn't even exist. So the override is just that we are
> >> "instantiating"
> >> a different resource than what was exported/virtualized.
> >
> > Note that multiple classes can realize a given resource. Thus, it
> > does matter, or at least, can.
Yes, you're right.
> I think the following two snippets should be managed by the same rules
> -- the same code if at all possible:
[snipped example]
That's exactly how it works. It ends up calling Compiler.add_override
for the same resource reference in both cases.
I just tested regular ressource override in the form of:
file {
"/tmp/testing": content => "pouet"
}
File["/tmp/testing"] { mode => 0600 }
File["/tmp/testing"] { group => devl }
This works, and doesn't impose to be in an inherited subscope.
Of course if we try to override the same parameter twice an error is
raised.
Did we loose the overriding in inherited classes only restriction?
Or maybe it has never been enforced?
--
Brice Figureau <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
