That's parse order dependent during compile (i.e. the order stuff gets included, parsed and magicked during compile etc) - anchors aren't really relevant here. So your commit has changed the include order I would expect.
Best either make them virtual and realize them, or wrap them both in if ! defined On 1 November 2013 16:52, Jesi Major <[email protected]> wrote: > We're having an issue where the catalog doesn't appear to be compiling in > the proper order, causing a resource to be defined twice (since the if ! > defined block runs first) and the catalog compilation to fail: > > Error: Could not retrieve catalog from remote server: Error 400 on SERVER: > Duplicate declaration: File[/data] is already declared in file > /etc/puppet/environments/jesim/modules/cassandra/manifests/config.pp:58; > cannot redeclare at > /etc/puppet/environments/jesim/modules/lvm/manifests/mount.pp:60 > > > We are aware of the behavior of resources creeping out of included classes, > so have anchored all classes involved in an attempt to resolve this issue. > Although doing this initially seemed to be ordering these resources > properly, another commit seems to have changed the order of catalog > compilation, causing the above error. > > This is the code snippet from the cassandra::config class, which is included > and anchored properly in the cassandra class: > > if ! defined( File['/data'] ) { > file { '/data': > ensure => 'directory', > before => File['cassandra-data-dir2'], > } > } > > And from lvm::mount defined type, which is defined in base::storage, which > is included and anchored in base, which is required by cassandra. > $mount_point is being passed as '/data' > > file { $mount_point: > ensure => 'directory', > } > > As far as I can tell, lvm should be running first, then cassandra, so the if > ! defined should work and it shouldn't be getting declared twice. And up > until the last commit I did, this is exactly how it was working. (We were > getting another error, as it appears the defined function doesn't look at > variables properly, so was still declaring it twice, but that's another > issue, and at least it was compiling in the appropriate order.) > > We were under the impression that proper anchoring would make the catalog > compile in the appropriate order, but I do not believe it is working. Is > this a known issue? Is there any way to work around this? Should this > definitely work and really our anchors might be fubared? I've looked through > them pretty closely, but there are defined types at play within > base::storage, and I'm not sure if those need anchoring as well. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/a4017005-a002-4235-8a04-50b88eac21e3%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAM87nnPd3KNSJ1mE2SQvMndnPKGpK91EZRrBRuFWSzdo2tqjoA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
