On Wed, 2008-10-15 at 09:41 -0500, Luke Kanies wrote:
> On Oct 15, 2008, at 3:36 AM, Brice Figureau wrote:
>
> >
> > 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?
>
> You mean not allowing an override in the defining class?
Yes.
> You can't replace an attribute's value in the defining class, but you
> can add new values. That way there's no conflict.
OK, my above manifest is then perfectly legit.
And the following one is legit too:
class t {
file { "/tmp/testing": content => "pouet" }
File["/tmp/testing"] { mode => 0600 }
}
class t2 inherits t {
File["/tmp/testing"] { mode => 0666 }
}
include t2
(Except it didn't change the mode to 0666, that's strange).
Since the collection overriding stuff I did for #1088 is using the exact
same codepath as resource overriding (except it appears later), I'm
pretty sure it follows exactly the same restrictions as the resource
overriding.
I'll perform more check later.
--
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
-~----------~----~----~----~------~----~------~--~---
