On Sep 12, 2013, at 1:15 PM, John Bollinger <[email protected]> wrote:
> > > 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]> 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. You're right; I hadn't thought of nodeless manifests. We'd need to do add them to the "can be top level without warnings" list. > 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? Why wouldn't it be? I would certainly be surprised if I were looking at the graph of classes and didn't see the site classes contained by the, um, site class. > 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. I'm not really committed to this; it just seemed like a way to encourage the right behavior without changing the functionality of the system. Do you have any ideas for how we might do that? > >> 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? Basically, I think there are very few cases where it actually makes sense to have top-level classes; few enough that it's worth telling the user about them because they probably want to fix it. If I'm right, then the choices are: * Rather than risk warning people about things that aren't actually problems, let users continue to struggle with ordering * Risk erroneous warnings and people sometimes having to add irrelevant containments in order for the vast majority of users to have a better experience If I'm wrong, of course, then the whole thing is pointless. But that's the trade off I'm thinking. > 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. Mostly, I think it is far more often the right outcome than not -- thus people working so hard to build anchors and such. I ran through the cases I could think of where a floating class both would happen and would be the right outcome; I literally can't think of other cases. Conversely, I can think of plenty negative aspects of floating classes that shouldn't be floating. Thus, why not help our users get rid of them? -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- 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.
