On 2013-26-09 21:39, Luke Kanies wrote:
On Sep 23, 2013, at 4:46 PM, John Bollinger <[email protected] <mailto:[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 [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.
