On Wednesday, September 11, 2013 3:14:41 PM UTC-5, Luke Kanies wrote:
>
> On Sep 11, 2013, at 12:32 PM, John Bollinger
> <[email protected]<javascript:>>
> wrote:
>
>
>
> On Wednesday, September 11, 2013 11:58:55 AM UTC-5, Trevor Vaughan wrote:
>>
>> This definitely works with the best practice of not having globally
>> floating classes.
>>
>>
>
> Please help me come up to speed here: why is it a best practice to avoid
> globally floating classes? If it truly doesn't matter when a given class
> is applied relative to any of the others, then how is it advantageous to
> declare ordering relationships for it? Does that not needlessly slow both
> master and agent, and make both more resource-hungry?
>
>
> Let's turn it around: What are the instances in which you would end up
> floating classes?
>
> E.g., what are the cases where you'd want a class to exist but have no
> concerns about its relationship to other classes?
>
> The only cases I can come up with are those that are specified at the node
> level, either in the ENC or in the Node.
>
> Every other class, almost by definition, must be in service to one of
> those top level classes, right?
>
Classes can be declared at top scope, too. The language docs themselves
note the possibility of skipping nodes altogether and simply using
top-scope conditionals to choose which classes to include in the catalog.
That's the basis for nodeless manifest sets.
Even if we consider only ENC- and node-declared classes, another class
being "in service to" one of those does not necessarily imply any essential
requirement for containment. For example, suppose I have a 'site' module,
declared at node level for all nodes, with this main class:
class site {
include 'site::motd'
include 'site::users'
}
Suppose further that 'site::motd' manages only nodes' /etc/motd file,
whereas 'site::users' manages login users. It is entirely reasonable that
neither of those has any ordering requirements relative to anything else
under management, so why should it be a best practice for class 'site' to
contain them?
Certainly, DSL authors need to pay careful attention to relationships,
probably moreso than most actually do. As such, I would be completely
comfortable with a recommendation that authors default to choosing
containment -- even one backed up by a warning, provided that it can be
disabled by users who know better in particular cases. I am not persuaded,
however, that unconditionally avoiding floating classes should be
considered a best practice.
A manifest set that omits needed relationships loses robustness, but a
manifest set that includes unneeded relationships loses resiliency and is
more costly. The best manifest set declares all needed relationships, but
no more.
>
> Are you OK with yelling at people that do though (for whatever reason)?
>>
>>
>
> Even if the assumption is that few classes are truly without ordering
> requirements, users should not be bullied / henpecked into declaring
> unneeded relationships. If it is desirable to warn users that they may
> have omitted needed relationships, then it is desirable to also afford them
> the opportunity to assert that they know better. At the coarsest level,
> that would mean a *continuing* ability to disable all such warnings, but
> ideal would be to support disabling the warnings on a class-by-class basis.
>
>
> Hrm, I don't think of it as henpecking, I think of it as encouraging but
> not requiring the right behavior, which I think we should do more of
> overall. I'm certainly not attached to the mechanism, or even whether it's
> a permanent thing or not; like my email said, it was just an idea, not
> something I'm trying to force through.
>
>
If rigorously avoiding floating classes (with select exceptions) were truly
the only right way to do things, then maybe it would be best to make it an *
error* to not do so. As it is, though, I'm still looking for an
explanation I can accept for why that should even be considered a superior
way of doing things. I'm serious: what am I missing here?
> As to how one would disable those behaviors, I guess we'd have to
> introduce another function or a pragma or something. That might not be
> worth it.
>
>
It's probably not worth supporting disabling the warning on a per-class
basis, unless it leveraged some existing, more general mechanism that
served other purposes as well. But one could still allow the warning to be
globally disabled via the config file.
A warning could be useful to help people catch classes that they did not
intend to allow to float. I'm really not arguing against implementing it;
rather I am challenging the best-practices position that allows it to be
cast as "encouraging [...] the right behavior." Sometimes why we do a
thing is just as important as what we actually do. And that cuts both
ways, too: if there's a good justification for containment as a best
practice, then I would like to be able to pay attention to it.
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
