On Thu, Aug 15, 2013 at 11:11 PM, Luke Kanies <[email protected]> wrote:
> On Aug 15, 2013, at 10:32 AM, Jeff McCune <[email protected]> wrote: > > On Thu, Aug 15, 2013 at 9:45 AM, Luke Kanies <[email protected]> wrote: > >> On Aug 15, 2013, at 9:40 AM, Jeff McCune <[email protected]> wrote: >> >> On Wed, Aug 14, 2013 at 3:25 PM, Andy Parker <[email protected]> wrote: >> >>> >>> >>>> Are we making any effort to help ensure end users who refactor their >>>> code don't end up with dramatically different behavior? >>>> >>> >>> The only effort that we are making, and that I think we can make, is to >>> keep promoting dependencies as the right way. As we were putting together >>> tests for this there were a couple cases that caught us by surprise about >>> the order in which things would be executed because of the relationship >>> between dependencies and manifest order. >>> >> >> This makes sense, but I do wonder if there's a way to implement ordering >> of resources within a manifest while also preserving the behavior of >> providing a stable ordering between manifests and classes as a whole. >> >> Is it feasible to provide a stable ordering of manifest files, regardless >> of the parse-order they were included, while also providing the parse >> ordering of resources within a class? >> >> >> What is the goal of that? >> > > The goal is to provide a user experience as close to as good as we have > currently. With the current behavior of Puppet users can change the > ordering of include statements and rest assured that the behavior of > catalog application is unaffected. With the new behavior described here I > no longer have this confidence. If I transpose two "include" lines then > the behavior of a puppet agent run will be very different and it's > difficult for the end user to predict what this new behavior will be. > > Today, all I have to do is write my manifests in any way I choose then do > a single puppet agent run. If I see the results I want to see then I'm > assured these results will persist and will have the same ordering across > the entire fleet. With the new behavior, if someone changes the ordering > of class declarations then it's difficult to predict what will happen > across the entire fleet. > > > Shouldn't it be exactly easy to predict the results? If someone changes > the order, the new order will be based on file order. Right? > There seems to be an assumption that file order is easy to predict. I don't think it is, at least it's not as I understand it to be currently implemented. It's not easy to predict the results. Classes are included in the catalog in many ways. include(), hiera_include(), external node classification, etc... With the current behavior, the workflow is simple to explain to new users. Write your code, run Puppet once. Did it do what you wanted? If yes, then you're assured these resources you've written will continue to do what you want even as you add or remove resources and if you move resources into any location in your classes or manifests. These resources will also behave in this manner across all nodes in the fleet, not just the one node you tested on. If no, it didn't do what you wanted, then you should probably specify the dependency because the dependency is important to you. In the new behavior I don't see a clear way to explain to new users how to manage a growing collection of resources being managed. The new user will need to understand that specifying classes in their ENC has an implicit ordering that matters. The same is true, they'll need to understand how hiera_include() works and that it's important to construct the array of classes in the order that matters. Worse, new users will need to understand that changing the ordering of classes specified in the ENC and in hiera_include() will actually have a significant impact on the behavior of the catalog runs. This isn't true today and users don't need to worry about it. Unless I'm misunderstanding the behavior of the current implementation, I believe quite strongly that we have a very real risk of making catalog application more complicated and difficult to understand even though we're doing so in an attempt to simplify the behavior and reduce the surprise new users experience. -Jeff -- 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.
