On Tuesday, July 8, 2014 3:16:46 PM UTC-5, henrik lindberg wrote:
>
> On 2014-08-07 18:09, John Bollinger wrote:
> > I tried hard to not like this, but then I recognized how congruent it is
> > -- or could be -- with one of my pet ideas: resource constraints. Felix
> > implemented part of that idea, but as I understand it, he handled only
> > the diagnostic part (recognizing whether constraints were satisfied) and
> > not the prescriptive part (updating the catalog, if possible, to ensure
> > that declared constraints /are/ satisfied).
> >
> > I don't much like the idea of "overriding" resource declarations as
> > such, but it's not such a big leap to reposition that as simply
> > declaring additional requirements (i.e. constraints) on resources that
> > (may) be declared elsewhere. We get the rest of the way to a limited
> > form of prescriptive constraints by collapsing this variety of resource
> > overrides with resource declarations. In other words, consider these
> > two expressions:
> >
> > file { '/tmp/hello': ensure => 'file' }
> > File { '/tmp/hello': ensure => 'file' }
> >
> > What if they meant exactly the same thing? Specifically, what if they
> > meant "there must be a resource in the catalog of type File and name
> > '/tmp/hello', having the value 'file' for its 'ensure' property"?
> > Either one would then insert such a resource into the catalog if
> > necessary, and afterward attempt to set the (then) existing resource's
> > 'ensure' parameter.
> >
> > I say "attempt to set" the existing resource's parameter, because I
> > think we still need to forbid modifying a value that was set (to a
> > different value) somewhere else. And that's more complicated than just
> > checking for undef, because it may be that undef is itself the
> > intentionally assigned parameter value, so that it would be an error to
> > change it. It also might need to be more permissive for subclasses and
> > collectors.
> >
> Note that collection currently can modify any already set value on all
> kinds of resources (regular, virtual and exported) at any point
> throughout the evaluation. How is it that these "rules" are given such
> mighty powers when a rule such as "File['tmp/foo'] { owner => x }" is
> not allowed to override a set mode of the same file? (I understand the
> need to guard against typos and unintentional changes). Basically I see
> File[id] { x => y } as the same expression as File <| title == id |> { x
> => y }.
>
>
Well, they are manifestly different at least in that the collector version
will realize the selected resource if need be. I anyway agree that there
is an issue there, but I'm not confident that I characterize it the same
way you do. That is, I don't think File[id] { x => y } is too weak;
rather, I think File<| title == id |> { x => y } is too strong. If one
part of my manifest set declares a property value for some resource, then
it is *wrong* for a different part to change it, because the result no
longer satisfies the original requirement.
There's some room to moderate that position a bit, of course. For example,
I have less objection to these kinds of changes being performed via
subclasses -- after all, that's the whole point of subclasses. One could
also argue, for instance, about whether it should be ok to override
parameters of virtual or exported resources. I think even these cases are
uncomfortable, but I'm not prepared advocate for their foreclosure against
the opposition that would surely arise.
> > We could go farther with that. If it seems wasteful to have two
> > different forms of the same statement, then we could apply additional
> > semantics to one or the other. For example, perhaps the lowercase form
> > could implicitly declare all unmentioned parameters as undef, with the
> > effect that they could not be overridden to anything different.. I
> > don't know whether that would be useful, or whether there is some other
> > behavior that would be more useful. Perhaps it would be best to just
> > let the two forms be equivalent, or maybe even to deprecate one.
> >
> >
> > Anyway, a few corner cases exist. A +> is only allowed if it is a
> > default or override expression.
> >
> >
> >
> > +> is a bit of a dark horse in the regime of overrides, as modifying a
> > previously-declared parameter value is inherent in its design. On the
> > other hand, it is currently useful for overrides only in subclasses and
> > collectors, where modifying a declared value is considered acceptable.
> > I don't think it's a major issue that evaluating a statement containing
> > a plussignment may yield an error, as long as the meaning of the
> > statement is not itself in question.
> >
>
> I like the direction this is going! You are absolutely right that
> basically all these expressions (resource attribute settings,
> "overrides", defaults) basically define a set of rules that together
> should define the resulting resources and the values of their attributes
> (call them constraints or rules).
>
> This would mean that +> would be perfectly valid even in definitions
> that does not modify something inherited, instead it basically says "use
> both what someone else said, and what I said" (if the parameter can hold
> multiple values).
>
>
Yes, that's a good reinterpretation. One of Puppet's weaknesses in this
area is that it currently has few good ways to distinguish parameter values
that are hard requirements from those that are preferences, nor to
distinguish inclusive requirements from exclusive ones. Using +> to
designate inclusive requirements would help that out some, at least for
multi-valued parameters.
>
> >
> > Do you like these ideas? Is it worth trying to make this work to try
> it
> > in practice? (it will take 1-2 days for the implementation, and a
> bit
> > more to fix all breaking tests).
> >
> >
> >
> > As I said before, I tried to dislike them, but I like them despite
> > myself. Especially if you're willing to accept my extension.
> >
> >
> Yes, I think your extension was that there is no difference between a
> LHS that is a type (e.g. Notify), and a lower case name of a type (e.g.
> notify). I agree completely.
>
>
Yes, that's basically it, but don't overlook that making it so requires
adjustments to the semantics of *both* kinds of statements.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/147cc4c1-60d0-486f-8874-6cab61720208%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
