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 <jessica.ma...@pearson.com> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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 puppet-dev+unsubscr...@googlegroups.com.
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.
