On Wed, Aug 14, 2013 at 1:53 PM, Jeff McCune <[email protected]> wrote:
> Andy,
>
> Am I understanding things correctly that the following two node
> definitions have different resource application ordering?
>
> node baz {
> include bar
> include foo
> }
>
> node baz {
> include foo
> include bar
> }
>
>
Yes. Absent any dependencies between resources those two nodes would end up
with different ordering for resource application. If you depended on that
order, then this would break that. If the manifests contained all of the
dependencies that matter, then this would not have a material effect on the
catalog application.
To give you a comparison. In the old system you would have gotten,
possibly, a similar problem if your refactor had been to rename the classes
instead of move the includes. The previous system used the names of the
resources to order things.
> 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.
>
> On Wednesday, August 14, 2013, Andy Parker wrote:
>
>> An update on this. Patrick and I have been working through this and the
>> changes have landed on the master branch. The final form is pretty much
>> exactly as outlined in the document that I originally linked to. It can be
>> summarized as, "When there is no other dependency information between
>> resources, they will be executed in the order they were added to the
>> catalog". The caveat (there always is one) is for agent-side generated
>> resources (for instance from recursive file resources). These are
>> technically added *after* all of the other resources in the catalog, but
>> they are logically added as part of the resource that generates them. In
>> that case those resources are inserted after the generating resource, but
>> before the next resource in the catalog.
>>
>> You can see the changes that we made to achieve this in these merges:
>>
>> *
>> https://github.com/puppetlabs/puppet/commit/6cc37d9eb39a22c800e28615f6b7022e8ec84e6f
>> *
>> https://github.com/puppetlabs/puppet/commit/41f00dca91361e87f6a029e44fa4a879b79341e1
>> *
>> https://github.com/puppetlabs/puppet/commit/989276e29b296fa7e28a5a7b9484615980c849f2
>>
>>
>> On Thu, Jul 11, 2013 at 5:42 PM, Andy Parker <[email protected]> wrote:
>>
>>> Ok, so what order do resources execute? Right now it is all determined
>>> by dependencies and by a "stable, yet opaque" ordering when there is
>>> nothing imposed. Opaquely ordering is great from a philosophical standpoint
>>> because by not having put in dependencies the system interprets that as the
>>> user not caring. Unfortunately sometimes you care about things, but don't
>>> know that you do :)
>>>
>>> So there has been some work going into creating a better "last resort"
>>> ordering of resources as has been discussed in
>>> http://projects.puppetlabs.com/issues/18508. Patrick Carlisle and I
>>> have been working through a few ideas for how to do this. At first blush it
>>> seemed like a bad idea because of the guarantee that we were interpreting
>>> it to be. After a bit of (heated) discussion the goal was changed to be a
>>> much laxer constraint on the system. In the absence of any other
>>> information and any possible reorderings, puppet will execute resources in
>>> the order in which they are added to the catalog (which is a close proxy to
>>> "file order").
>>>
>>> So that said please take a look and see if this is a wrong-headed idea
>>> and we should stop the train :)
>>>
>>> Doc is linked from the redmine issue, but for all you all's convenience:
>>> https://docs.google.com/document/d/1vouD3tAtHD43rUVbPtVDuVQ_zMxhxMejIpzNIP7qM2s/edit?usp=sharing
>>>
>>> --
>>> Andrew Parker
>>> [email protected]
>>> Freenode: zaphod42
>>> Twitter: @aparker42
>>> Software Developer
>>>
>>> *Join us at PuppetConf 2013, August 22-23 in San Francisco - *
>>> http://bit.ly/pupconf13*
>>> **Register now and take advantage of the Early Bird discount - save 25%!
>>> *
>>>
>>
>>
>>
>> --
>> Andrew Parker
>> [email protected]
>> Freenode: zaphod42
>> Twitter: @aparker42
>> Software Developer
>>
>> *Join us at PuppetConf 2013, August 22-23 in San Francisco - *
>> http://bit.ly/pupconf13*
>> **Register now and take advantage of the Final Countdown discount - save
>> 15%!*
>>
>> --
>> 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.
>>
>
>
> --
> *Jeff McCune <http://jeffmccune.com/>*
> Join us at PuppetConf 2013 <http://bit.ly/pupconf13>, August 22-23 in San
> Francisco
>
> --
> 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.
>
--
Andrew Parker
[email protected]
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*
--
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.
