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+unsubscr...@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.
