Just out of curiosity, isn't this very similar to setting freeze_main = true for your master? This would explicitly disallow any floating resources.
So, would a potential course of action be to allow freeze_main = warn. Have this be the default for <next version> and then move to freeze_main = true for <next version +1>. Thanks, Trevor On Thu, Sep 26, 2013 at 4:38 PM, Henrik Lindberg < [email protected]> wrote: > On 2013-26-09 21:39, Luke Kanies wrote: > >> On Sep 23, 2013, at 4:46 PM, John Bollinger <[email protected] >> <mailto:john.bollinger@stjude.**org <[email protected]>>> wrote: >> >> >>> >>> On Sunday, September 22, 2013 5:22:10 PM UTC-5, Luke Kanies wrote: >>> >>> >>> On Sep 19, 2013, at 11:35 AM, John Bollinger >>> <[email protected] <javascript:>> wrote: >>> >>> On Tuesday, September 17, 2013 1:36:34 PM UTC-5, Luke Kanies wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> So what's wrong with defaulting to the latter, and allowing users >>>> to opt for the former? The ability to silence unwanted warnings >>>> is a highly desirable feature, especially in shops where warnings >>>> are considered errors. >>>> >>> >>> Sure. I'd even go so far as to say we should maybe only add the >>> warnings in a strict mode, or have a special mode that throws more >>> warnings. >>> >>> >>> >>> It's clear that we aren't going to reach an agreement about whether >>> it's a good idea to strive for full containment (subject to the >>> exceptions we already discussed), much less whether doing so should be >>> considered a best practice. We have differing objectives, which I >>> hope you and the rest of the PL team will bear in mind going forward. >>> >>> On the other hand, it seems like we have no real disagreement about >>> the warnings themselves. As for a strict / high-warnings mode, that >>> sounds good to me. As much as it is useful to be able to silence >>> unwanted warnings, it is also useful to be able to ask for extreme >>> nitpick mode to troubleshoot problems, or for the forward thinking >>> among us, to try to avoid problems in the first place. >>> >>> Thanks for your patience. >>> >> >> Do we have agreement that it's a good idea to find a way to encourage >> users to provide more dependencies, and that it would be good if we >> could somehow detect when a dependency is likely to be missing? >> >> If we can agree on that, then maybe we can find a mechanism (which may >> or may not involve containment) we can agree on. If we can't agree on >> that, then yeah, we're not going to agree. :) >> >> > To me it sounds like the debate is whether "non containment" is a problem, > or something that is wanted. In either case, the important thing is to > communicate to the user what the sum of their manifests results in. You can > currently view this in a graph say, but it may not be apparent to the user > why they should do that, or what they should be looking for. > > How about producing a warning about "There are n classes in the catalog > without dependencies. These are processed in an undefined order - run the > command XXX to show more information and review if this is acceptable." > > Then have a command that shows the information; dependency chains and what > is in no dependency chain - a graph or textual. > > The warning is a simple toggle, those that know more can simply turn it > off, and use the command to view dependencies as part of their work. (i.e. > there will continue to be things that do not depend on anything else and > they would always see the warning otherwise). We could also have a simply > cap which they can set (not sure it will be valuable in practice, it may > require a list of which classes that they allow to float off, and then it > starts to become difficult). > > Just some ideas... > > - henrik > > > -- > 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 > puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
