> I'm trying my hand at my first exported resource. In fact, this comes from
> converting an older resource to an exported one, which might explain the
> problem....
>
> Currently, I have two classes:
>
> class yum {
> File <<| tag == 'repofile' |>> ~> Exec['yum clean all']
> :
> }
>
> class yum::foo {
> include yum
> @@file { 'foo-yum':
> tag => 'repofile',
> path => '/etc/yum.repos.d/foo.repo',
> ensure => file,
> source => 'puppet:///modules/yum/foo.repo',
> }
> }
>
> When I try to run this by including yum::foo in a class, I get this error:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Another local or imported resource exists with the type and title
> File[foo-repofile] on node osem2.foo.net
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> #
>
> So I go looking for anything containing foo-repofile:
>
> # cd /etc/puppet/modules && find . -type f | xargs grep foo-repofile
> #
>
> ORIGINALLY, this resource was called foo-repofile, but at that time, it was
> in a different module and wasn't exported. How can I purge that from
> PuppetDB so it gets over it and lets me use this new one? Or is the the
> problem somewhere or something else?
So this is a duplicate exported resource. Something in your content
has created this scenario at some time, and its usually either a)
genuine, you really have exported the same type/title combination
twice from two nodes, and are now collecting it onto one, a constraint
violation or b) an old node has exported this in the past, and that
node has not been deactivated.
The trick is to figure out how to debug these issues, since they are
often quite solveable.
Zach Smith has created a tool for analyzing what has been exported to
PuppetDB: http://forge.puppetlabs.com/zack/exports and this is a great
start.
You can also query this manually yourself:
$ curl 'http://localhost:8080/v3/resources?query=\["=","exported",true\]'
In general, the trick to avoid this error is to make sure the types
you export can never collide. In your code:
@@file { 'foo-yum':
path => '/etc/yum.repos.d/foo.repo',
}
... you are exporting something with a very fixed title and namevar
(foo-yum and path respectively) ... basically if two nodes export
this, you will always get a collision on the collecting host, so the
pattern you have will only work if there is 1 export, or if you pin
the collection query to the node that exported it.
To be honest though - exported resources might not be appropriate for
this yum repo use case anyway, although perhaps I don't see it :-).
Can you explain why you are trying to use exported resources for this
purpose?
ken.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAE4bNTmXwwyYwBG6aR9cNc%2BjS_MzLvoaeBaOSPT5XhCkwSQxFw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
