François Lafont
2013-Aug-27 06:51 UTC
[Puppet Users] Problem of ordering with exported files
Hi, I use Puppet 3.2 (with hiera) on Debian Wheezy and I have a problem of ordering with exported files. I have 2 puppet clients : 1) server.mydomain.priv with this yaml: --- classes: - test::server 2) and node.mydomain.priv with this yaml: --- classes: - test::node Here is my (very simple) "test" module: --------------------------------------- class test::node { @@file { "${::hostname}_exported": path => "/usr/local/puppet_host/exported/${::hostname}_exported", content => "node\n", tag => "exported", } } --------------------------------------- And --------------------------------------- class test::server { $managed_directories = [ ''/usr/local/puppet_host'', ''/usr/local/puppet_host/exported'', ] file { $managed_directories: ensure => directory, mode => 750, recurse => true, force => true, } file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } File <<| tag == ''exported'' |>> { mode => 0644, } # Ordering File[$managed_directories] -> File[''/usr/local/puppet_host/list''] -> File <<| tag == ''exported'' |>> # <-- exported files at the end !!! } --------------------------------------- No problem when I run puppet on node.mydomain.priv. But after, on server.mydomain.priv, I have this: root@server:~# puppet agent --test Info: Retrieving plugin Info: Caching catalog for server.mydomain.priv Info: Applying configuration version ''1377583717'' Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure: created Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure: created Notice: /Stage[main]/Test::Server/File[node_exported]/ensure: defined content as ''{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'' Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined content as ''{md5}62171c0c9812eb038aa53a42e30a97f8'' Notice: Finished catalog run in 0.08 seconds In the test::server class, I have forced the exported file to be created at the end. But, during the puppet run, this is not the case, and the File[/usr/local/puppet_host/list] resource is realized *after* the exported file. Why? Is it normal? Did I forget anything? How I can force the exported file to be created at the end? Thanks in advance for your help. -- Francois Lafont -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
François Lafont
2013-Aug-27 12:39 UTC
[Puppet Users] Re: Problem of ordering with exported files
Le 27/08/2013 08:51, François Lafont a écrit :> In the test::server class, I have forced the exported file to be > created at the end. But, during the puppet run, this is not the case, > and the File[/usr/local/puppet_host/list] resource is realized *after* > the exported file.I''m wondering if this is not a bug. If I just change the *title* of the exported file, the order is correct. --------------------------------------- class test::node { ## @@file { "${::hostname}_exported": <----- I just change the title. @@file { "${::hostname}": # <----- The new title content => "node\n", tag => "exported", path => "/usr/local/puppet_host/exported/${::hostname}_exported", } } --------------------------------------- Then: root@node:~# puppet agent --test Info: Retrieving plugin Info: Caching catalog for node.mydomain.priv Info: Applying configuration version ''1377606380'' Notice: Finished catalog run in 0.02 seconds And: root@server:~# rm -r /usr/local/puppet_host/; puppet agent --test Info: Retrieving plugin Info: Caching catalog for server.mydomain.priv Info: Applying configuration version ''1377606673'' Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure: created Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure: created Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined content as ''{md5}62171c0c9812eb038aa53a42e30a97f8'' Notice: /Stage[main]/Test::Server/File[node]/ensure: defined content as ''{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'' Notice: Finished catalog run in 0.07 seconds Here, the exported file is created at the end of the puppet run. Is it normal that the order changes just with a modification of the title resource? Thanks in advance. -- Francois Lafont -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
jcbollinger
2013-Aug-27 19:23 UTC
[Puppet Users] Re: Problem of ordering with exported files
On Tuesday, August 27, 2013 1:51:50 AM UTC-5, François Lafont wrote:> > Hi, > > I use Puppet 3.2 (with hiera) on Debian Wheezy and I have > a problem of ordering with exported files. > > I have 2 puppet clients : > > 1) server.mydomain.priv with this yaml: > > --- > classes: > - test::server > > 2) and node.mydomain.priv with this yaml: > > --- > classes: > - test::node > > Here is my (very simple) "test" module: > > --------------------------------------- > class test::node { > > @@file { "${::hostname}_exported": > path => > "/usr/local/puppet_host/exported/${::hostname}_exported", > content => "node\n", > tag => "exported", > } > > } > --------------------------------------- > > And > > --------------------------------------- > class test::server { > > $managed_directories = [ > ''/usr/local/puppet_host'', > ''/usr/local/puppet_host/exported'', > ] > > file { $managed_directories: > ensure => directory, > mode => 750, > recurse => true, > force => true, > } > > file { ''/usr/local/puppet_host/list'': > mode => 440, > content => "List.\n", > } > > File <<| tag == ''exported'' |>> { > mode => 0644, > } > > # Ordering > File[$managed_directories] > -> File[''/usr/local/puppet_host/list''] > -> File <<| tag == ''exported'' |>> # <-- exported files at the end > !!! > } > --------------------------------------- > > No problem when I run puppet on node.mydomain.priv. But after, > on server.mydomain.priv, I have this: > > root@server:~# puppet agent --test > Info: Retrieving plugin > Info: Caching catalog for server.mydomain.priv > Info: Applying configuration version ''1377583717'' > Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure: > created > Notice: > /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure: > created > Notice: /Stage[main]/Test::Server/File[node_exported]/ensure: defined > content as ''{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'' > Notice: > /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined > content as ''{md5}62171c0c9812eb038aa53a42e30a97f8'' > Notice: Finished catalog run in 0.08 seconds > > In the test::server class, I have forced the exported file to be > created at the end. But, during the puppet run, this is not the case, > and the File[/usr/local/puppet_host/list] resource is realized *after* > the exported file. > > Why? Is it normal? Did I forget anything? > How I can force the exported file to be created at the end? > >I don''t see anything obviously forgotten or wrong, but there are a few strange things: 1. You collect the same exported File resources twice in the same class. I wouldn''t have expected that to be a problem, but unusual code is more likely to tickle bugs. I suspect that this is indeed where your trouble lies. 2. You seem to be declaring relationships that for the most part duplicate those that Puppet can normally be relied upon to create automatically ("autodepends"). Specifically, if a file and its parent directory are both under management, and no relationship is otherwise declared between them, then Puppet will automatically manage the directory before the file. Explicitly declaring the same relationships is not an error, however. 3. You are declaring recursive directories without any ''source'' parameters. That probably does not mean what you think it means, because in that case the recursiveness has no effect. 4. You declare ''force => true'', which is only necessary to enable clobbering existing directories, but the other parameters don''t contain anything that could make that needful. 5. You declare that File[''/usr/local/puppet_host/list''] must be applied before any of the exported Files tagged ''exported'', but that does not appear to be needful. Still, that''s not erroneous. I might write class test::server more like this: class test::server { file { [ ''/usr/local/puppet_host'', ''/usr/local/puppet_host/exported'' ]: ensure => directory, mode => 750 } file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } File <<| tag == ''exported'' |>> { mode => 0644, } } For explicit relationships, either declare them via the ''require'' and/or ''before'' metaparameters, or put chain operators between the declarations above as needed. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
François Lafont
2013-Aug-27 23:47 UTC
Re: [Puppet Users] Re: Problem of ordering with exported files
Hello, Firstly, thank you John for your answer. Le 27/08/2013 21:23, jcbollinger wrote :> I don''t see anything obviously forgotten or wrong, but there are a few > strange things:It''s possible. ;-)> 1. You collect the same exported File resources twice in the same > class.Really? In fact, I have tried to follow this doc: http://docs.puppetlabs.com/learning/ordering.html#chaining-arrows where you can see this example: ---------------------------------------- # 1. One declaration. file {''/tmp/test1'': ensure => present, content => "Hi.", } # 2. Another one. notify {''after'': message => ''/tmp/test1 has already been synced.'', } # 3. Ordering. File[''/tmp/test1''] -> Notify[''after''] ---------------------------------------- And the same page tells: "Chaining arrows can take several things as their operands: this example uses resource references, but they can also take resource declarations and resource collectors." As a result, I have deduced that this code below was correct *and* not redundant: ---------------------------------------- # 1. One declaration. file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } # 2. Another one. File <<| tag == ''exported'' |>> { mode => 0644, } # 3. Ordering. File[''/usr/local/puppet_host/list''] -> File <<| tag == ''exported'' |>> ---------------------------------------- Am I wrong? * file { ''/tmp/a'': } is a resource declaration * File[''/tmp/a''] is a resource reference (for the chaining by example) but not a declaration And I thought that File <<| tag == ''exported'' |>> was a resource reference but not a resource declaration. In fact, it seems to me that a resources collector is a resources declaration *and* a resource reference. This point is not very clear for me... If I understand, the code above is correct but redundant, is''nt it? And the correct and not redundant way with chaning is: ---------------------------------------- file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } -> File <<| tag == ''exported'' |>> { mode => 0644, } ---------------------------------------- Is that correct? Is it possible to separate declaration and after chaining like in the first example? Perhaps it''s impossible with exported resources...> I wouldn''t have expected that to be a problem, but unusual code is > more likely to tickle bugs.Yes and I don''t like to tickle bugs. ;-) This is why I want to follow the good practices (when it will be clear in my spirit).> I suspect that this is indeed where your > trouble lies.It''s possible. I think It''s will be more clear at the end of this post. ;-)> 2. You seem to be declaring relationships that for the most part > duplicate those that Puppet can normally be relied upon to create > automatically ("autodepends"). Specifically, if a file and its parent > directory are both under management, and no relationship is otherwise > declared between them, then Puppet will automatically manage the directory > before the file. Explicitly declaring the same relationships is not an > error, however.Yes, I understand that. But sometimes we want to force ordering.> 3. You are declaring recursive directories without any ''source'' > parameters. That probably does not mean what you think it means, because > in that case the recursiveness has no effect. > 4. You declare ''force => true'', which is only necessary to enable > clobbering existing directories, but the other parameters don''t contain > anything that could make that needful.Sorry it''s my fault, I have forgotten ''purge => true'' in my code. So, in fact it''s: file { $managed_directories: ensure => directory, mode => 750, purge => true, recurse => true, force => true, } I hope it''s consistent now.> 5. You declare that File[''/usr/local/puppet_host/list''] must be applied > before any of the exported Files tagged ''exported'', but that does not > appear to be needful.Yes, because my example is an "MCE" (Minimal and Complete Example that shows my problem). Indeed, in this example this is''nt needful but in my real puppet code this is needful, I want to create the exported files in an precise moment (and my reasons are valid to my mind but irrelevant in this post).> I might write class test::server more like this: > > class test::server { > file { [ ''/usr/local/puppet_host'', > ''/usr/local/puppet_host/exported'' ]: > ensure => directory, > mode => 750 > } > > file { ''/usr/local/puppet_host/list'': > mode => 440, > content => "List.\n", > } > > File <<| tag == ''exported'' |>> { > mode => 0644, > } > } > > For explicit relationships, either declare them via the ''require'' and/or > ''before'' metaparameters,I don''t know why, but I prefer the chaining. Perhaps because I found it''s more explicit and visual (this is a personnal opinion).> or put chain operators between the declarations > above as needed.Ok, something like that if I understand: class test::server { # ... file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } -> File <<| tag == ''exported'' |>> { mode => 0644, } } Is it possible to separate declaration and ordering? In any case, indeed, with the code above, the order is correct, exactly as I want. But I want to separate declarations first and then the chaining I haven''t the good order. Thank a lot for your help John. -- Francois Lafont -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
jcbollinger
2013-Aug-28 14:53 UTC
Re: [Puppet Users] Re: Problem of ordering with exported files
On Tuesday, August 27, 2013 6:47:41 PM UTC-5, François Lafont wrote:> > Hello, > > Firstly, thank you John for your answer. > > Le 27/08/2013 21:23, jcbollinger wrote : > > > I don''t see anything obviously forgotten or wrong, but there are a few > > strange things: > > It''s possible. ;-) > > > 1. You collect the same exported File resources twice in the same > > class. > > Really? >Yes.> > In fact, I have tried to follow this doc: > http://docs.puppetlabs.com/learning/ordering.html#chaining-arrows > where you can see this example: > > ---------------------------------------- > # 1. One declaration. > file {''/tmp/test1'': > ensure => present, > content => "Hi.", > } > > # 2. Another one. > notify {''after'': > message => ''/tmp/test1 has already been synced.'', > } > > # 3. Ordering. > File[''/tmp/test1''] -> Notify[''after''] > ---------------------------------------- > > And the same page tells: > > "Chaining arrows can take several things as their > operands: this example uses resource references, but they can also take > resource declarations and resource collectors." > > As a result, I have deduced that this code below was correct *and* not > redundant: > > ---------------------------------------- > # 1. One declaration. > file { ''/usr/local/puppet_host/list'': > mode => 440, > content => "List.\n", > } > > # 2. Another one. > File <<| tag == ''exported'' |>> { > mode => 0644, > } > > # 3. Ordering. > File[''/usr/local/puppet_host/list''] -> File <<| tag == ''exported'' |>> > ---------------------------------------- > > Am I wrong? >Yes. The code is at least redundant, in that both appearances of File <<| tag == ''exported'' |>> specify the inclusion of the matching resources in the target node''s catalog, regardless of the fact that they appear in contexts that carry distinct additional implications. In fact, when you bring resource property overrides into the picture as you have done, multiple collections of the same resources could be construed as conflicting.> > * file { ''/tmp/a'': } is a resource declaration > * File[''/tmp/a''] is a resource reference (for the chaining by example) > but not a declaration > > And I thought that File <<| tag == ''exported'' |>> was a resource reference > but not a resource declaration. In fact, it seems to me that a resources > collector is a resources declaration *and* a resource reference. This > point is not very clear for me... >That is understandable, as the syntax is a bit magic. Collectors are not declarations of individual resources, but they *are* declarations of * collections* of zero or more individual resources declared elsewhere. The most fundamental effect of a collection declaration is to ensure that the collected member resources are included in the target node''s catalog. Above and beyond that, they can be used to additionally override parameters of member resources and in chaining expressions. Those are also capabilities of resource references (but also of individual resource declarations, more or less). And multiple declarations of the same collection are not construed as erroneous, though I''m suggesting that they might not work as you would expect in that case.> > If I understand, the code above is correct but redundant, is''nt it? > And the correct and not redundant way with chaning is: > > ---------------------------------------- > file { ''/usr/local/puppet_host/list'': > mode => 440, > content => "List.\n", > } > > -> > > File <<| tag == ''exported'' |>> { > mode => 0644, > } > ---------------------------------------- > > Is that correct? >That is certainly non-redundant, and it looks correct to me. Alternatively, you could accomplish the same thing by using the ''require'' metaparameter instead of the chaining operator: file { ''/usr/local/puppet_host/list'': mode => 440, content => "List.\n", } File <<| tag == ''exported'' |>> { mode => 0644, require => File[''/usr/local/puppet_host/list''] } in which case you could separate the two stanzas, even into different classes.> > Is it possible to separate declaration and after chaining like in the > first > example? Perhaps it''s impossible with exported resources... > >That''s the thing. The syntax seems to support it, just as you originally wrote, and I would expect your original code to do what you wanted. I cannot explain why it doesn''t; I''m just trying to help you find a workaround.> > > I wouldn''t have expected that to be a problem, but unusual code is > > more likely to tickle bugs. > > Yes and I don''t like to tickle bugs. ;-) > This is why I want to follow the good practices (when it will be clear in > my spirit). > > > I suspect that this is indeed where your > > trouble lies. > > It''s possible. I think It''s will be more clear at the end of this > post. ;-) > >[...]> 3. You are declaring recursive directories without any ''source'' > > parameters. That probably does not mean what you think it means, > because > > in that case the recursiveness has no effect. > > 4. You declare ''force => true'', which is only necessary to enable > > clobbering existing directories, but the other parameters don''t > contain > > anything that could make that needful. > > Sorry it''s my fault, I have forgotten ''purge => true'' in my code. So, in > fact > it''s: > > file { $managed_directories: > ensure => directory, > mode => 750, > purge => true, > recurse => true, > force => true, > } > > I hope it''s consistent now. >The ''force'' makes sense then, but I think the ''recurse'' will still be without any effect. That is, I don''t think it will cause the purge to descend into managed subdirectories. Perhaps I am mistaken about that, though.> > 5. You declare that File[''/usr/local/puppet_host/list''] must be > applied > > before any of the exported Files tagged ''exported'', but that does not > > appear to be needful. > > Yes, because my example is an "MCE" (Minimal and Complete Example that > shows my > problem).Fair enough. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
François Lafont
2013-Aug-29 21:59 UTC
Re: [Puppet Users] Re: Problem of ordering with exported files
Le 28/08/2013 16:53, jcbollinger wrote :>> As a result, I have deduced that this code below was correct *and* not >> redundant: >> >> ---------------------------------------- >> # 1. One declaration. >> file { ''/usr/local/puppet_host/list'': >> mode => 440, >> content => "List.\n", >> } >> >> # 2. Another one. >> File <<| tag == ''exported'' |>> { >> mode => 0644, >> } >> >> # 3. Ordering. >> File[''/usr/local/puppet_host/list''] -> File <<| tag == ''exported'' |>> >> ---------------------------------------- >> >> Am I wrong? >> > > > Yes. The code is at least redundant, in that both appearances of > > File <<| tag == ''exported'' |>> > > specify the inclusion of the matching resources in the target node''s > catalog, regardless of the fact that they appear in contexts that carry > distinct additional implications.Ok, so if I follow your logic, this simple code below is correct and redundant too, isn''t it? (and the rendundancy is not a problem) ---------------------------------------- # 1. One declaration. file {''/tmp/test1'': ensure => present, content => "Hi.", } # 2. Another one. notify {''after'': message => ''/tmp/test1 has already been synced.'', } # 3. Ordering. File[''/tmp/test1''] -> Notify[''after''] ---------------------------------------->> If I understand, the code above is correct but redundant, is''nt it? >> And the correct and not redundant way with chaning is: >> >> ---------------------------------------- >> file { ''/usr/local/puppet_host/list'': >> mode => 440, >> content => "List.\n", >> } >> >> -> >> >> File <<| tag == ''exported'' |>> { >> mode => 0644, >> } >> ---------------------------------------- >> >> Is that correct? >> > > > That is certainly non-redundant, and it looks correct to me.[...]>> Is it possible to separate declaration and after chaining like in the >> first >> example? Perhaps it''s impossible with exported resources... >> >> > > That''s the thing. The syntax seems to support it, just as you originally > wrote, and I would expect your original code to do what you wanted.We agree. ;-)> I cannot explain why it doesn''t;Me too. Don''t you think that it can be interpreted as a little bug? (or just a inconsistency?) It''s very curious, if I just change the title of the exported files, then the order is as we expect (I give an example in my message #2).> I''m just trying to help you find a workaround.You don''t try, you succeed in doing so and I thank you for that. ;-) -- Francois Lafont -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
jcbollinger
2013-Aug-30 13:20 UTC
Re: [Puppet Users] Re: Problem of ordering with exported files
On Thursday, August 29, 2013 4:59:16 PM UTC-5, François Lafont wrote:> > Le 28/08/2013 16:53, jcbollinger wrote : > > >> As a result, I have deduced that this code below was correct *and* not > >> redundant: > >> > >> ---------------------------------------- > >> # 1. One declaration. > >> file { ''/usr/local/puppet_host/list'': > >> mode => 440, > >> content => "List.\n", > >> } > >> > >> # 2. Another one. > >> File <<| tag == ''exported'' |>> { > >> mode => 0644, > >> } > >> > >> # 3. Ordering. > >> File[''/usr/local/puppet_host/list''] -> File <<| tag == ''exported'' |>> > >> ---------------------------------------- > >> > >> Am I wrong? > >> > > > > > > Yes. The code is at least redundant, in that both appearances of > > > > File <<| tag == ''exported'' |>> > > > > specify the inclusion of the matching resources in the target node''s > > catalog, regardless of the fact that they appear in contexts that carry > > distinct additional implications. > > Ok, so if I follow your logic, this simple code below is correct and > redundant too, isn''t it? (and the rendundancy is not a problem) > > ---------------------------------------- > # 1. One declaration. > file {''/tmp/test1'': > ensure => present, > content => "Hi.", > } > > # 2. Another one. > notify {''after'': > message => ''/tmp/test1 has already been synced.'', > } > > # 3. Ordering. > File[''/tmp/test1''] -> Notify[''after''] > ---------------------------------------- > >No, that is not redundant. Resource references do not direct Puppet to include the referenced resources in the target node''s catalog. Instead, they depend on those resources being declared by other means, else catalog compilation will fail. Collectors are different, partly because they combine two distinct functions: 1. to realize virtual resources or import exported resources (depending on the form of the collector), and 2. to serve essentially as a reference to the whole group of collected resources It is with respect to the former that collecting the same resources multiple times is redundant, and ordinary resource references do not serve that purpose. Nevertheless, I''m really just trying to rationalize the odd behavior you observed. I would not have expected your original code to exhibit the problems it did, and I think it would be better for Puppet to behave as you expected in this regard.> Me too. Don''t you think that it can be interpreted as a little bug? (or > just a inconsistency?) >Yes, I think it would be reasonable to interpret the behavior as buggy. I think you would be justified in filing a bug ticket with PuppetLabs over this. There might even be one already; I didn''t check.> > It''s very curious, if I just change the title of the exported files, > then the order is as we expect (I give an example in my message #2). > >I think that''s just luck. Your original code clearly does not result in the desired ordering relationship being included in the node''s catalog. Where relationships do not constrain the relative order of two resources, Puppet is free to apply them in either order. In practice, it uses an order that is essentially unpredictable, but that remains stable *provided that the affected resources do not change*. Changing resource titles, however, can result in a different order of application. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.