On Thu, Jun 27, 2013 at 5:55 AM, <mpouns...@afilias.info> wrote:
>
>
> On Thursday, June 27, 2013 7:26:34 AM UTC-4, Ken Barber wrote:
>>
>> Perhaps if you can provide a code snippet like the simplified case
>> above we can take a look at what is going wrong. Also - what version
>> of Puppet are you running?
>>
>
> > facter puppetversion
> 2.7.21 (Puppet Enterprise 2.8.2)
>
> Your code snipped doesn't work because, according to the Exported
> Resources docs[1], 'storeconfigs' is enabled in the [master] section of
> puppet.conf, and therefore isn't set for 'puppet apply'.
>
> I built a small module though and tried with that and it works... so now
> I'm trying to figure out what's different about that vs. my actual use
> case. I'm at a loss.
>
> This is the part of the manifest that's the problem. In the block below,
> ${site} is a custom fact that gives me the data centre name, and it's
> pulled from the FQDN of the server; ${pad_index} is a zero-padded customer
> number, to give a simplified explanation.
>
> This bit is part of a larger collection of files that are assembled into a
> final config by the Exec that's referenced. There are two "mgmt" class
> servers, and the first @@file resource is never picked up in the File
> <<||>> collector by the node where it was defined. That is, mgmt1 gets
> mgmt2's resource, but not its own. I had to stick in the second,
> non-exported resource, to make it work. Note that even though the exported
> resource doesn't get realized, I'm still seeing duplicate declarations if I
> have the two resources named the same, thus the 'exported' and 'own'
> strings added to the resource titles.
>
> # This needs to go on *both* mgmt servers (one from each) so
> it's
> # an exported resource just like from the app servers.
> @@file { "${pad_index}-${title}-${fqdn}-exported-hcdV.conf":
> path =>
> "${hcdVdir}/healthcheckd.conf.d/${pad_index}-${fqdn}.
> conf",
> owner => $::aconfig::params::user,
> group => $::aconfig::params::group,
> mode => 0644,
> content => template("aconfig/hcdV-instance-mgmt.conf.erb"),
> notify => Exec["hcdV.conf-${title}-refresh"],
> tag => "hcdV.conf-${title}-${site}",
> }
> # Temporary workaround .. exported resources aren't picked up
> by
> # the server that defined them, so we have to define this
> resource
> # twice. One of these will probably start throwing an error
> when
> # the bug is fixed.
> file { "${pad_index}-${title}-${fqdn}-own-hcdV.conf":
> path =>
> "${hcdVdir}/healthcheckd.conf.d/${pad_index}-${fqdn}.conf",
> owner => $::aconfig::params::user,
> group => $::aconfig::params::group,
> mode => 0644,
> content => template("aconfig/hcdV-instance-mgmt.conf.erb"),
> notify => Exec["hcdV.conf-${title}-refresh"],
> tag => "hcdV.conf-${title}-${site}",
> }
>
> #
> # collects all the hcdV config files for this site/vertical
> File <<| tag == "hcdV.conf-${title}-${site}" |>>
>
> Perhaps another pair of eyes will pick up what I'm missing... why is the
> behaviour here different from the simplified test? For reference, this was
> my test module, which worked as expected:
>
Might be the usage of dash in the tag. Puppet had a series of bugs related
to dash. I would look at the generated catalog and see what are the tags
associated with the resource. For example:
reference:
File[/opt/puppet/libexec/mcollective/mcollective/agent/package.ddl]
tags:
- file
- class
- "pe_mcollective::server::plugins"
- pe_mcollective
- default
This should confirm whether the bug is with usage of dash or collection of
resources.
HTH,
Nan
--
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.
