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 :-(
> 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.
> >
> >> 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"] }
> >
> > 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...).
> For overrides, though, relationship params stack, so you'd get both.
Cool, I thought it was overwriting parameters, including relationship
params.
> > 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?
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.
> >
> > 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.
OK, I'll publish the patch later this week.
Thanks,
--
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
-~----------~----~----~----~------~----~------~--~---
