Exported resource resolving oddly

[Bret Wortman]

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?

Thanks!

Bret

[Ken Barber]

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.

[Bret Wortman]

It's partly to experiment with something I just learned, in all honesty. But it's also because this is a resource that I only want on certain systems, and after installing it (or any yum file for that matter), I want to trigger a "yum clean all" so that puppet doesn't spin for a while before yum finally discovers the new yumfile. So collecting it in the yum module permits me to only have the "yum clean all" exec defined in one place, triggered by the collection. And it permits me to add other, system-specific and application-specific repos from time to time as needed as well. These are usually put together by our developers, not repos that we're trying to pull from the internet.

I'll readily admit it may not be the best use, but it's proving a good learning experience.

I tried altering the title by embedding $hostname, but that didn't help. What if I embed $title within the namevar instead, and changed title to be the actual filename? I'll try that next....

Bret Wortman

http://about.me/wortmanbret

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

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.

[Bret Wortman]

The curl command, incidentally, returned nothing on the server, and errored on the client when typed in verbatim. And from the client, when I changed "localhost" to the name of the puppet master, I got a "curl (7): couldn't connect to host" error. I'll try Zach's tool next.

Bret Wortman

http://about.me/wortmanbret

On Thu, Nov 21, 2013 at 10:53 AM, Ken Barber <k...@puppetlabs.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

[Bret Wortman]

Wait -- so this collects every occurrence thoughout the database, not just for the system being processed? I think the word "node" was tripping me up in the online documentation -- I was reading "node" and thinking "resource". Okay, I get it now, and you're absolutely right -- this is a terrible use of exported resources. I think what I was looking for was virtual, not exported, resources.

Bret Wortman

http://about.me/wortmanbret

[jcbollinger]

On Thursday, November 21, 2013 10:29:37 AM UTC-6, Bret Wortman wrote:

Wait -- so this collects every occurrence thoughout the database, not just for the system being processed?

Yes, that's the point of exported resources.  They allow resources the catalog compilation process for one node's catalog to emit resource declarations that are available for incorporation into ANY node's catalog.  It only makes sense to do this with resources that are in some way specific to the exporting node.  The canonical example is Host resources -- if each node exports a Host resource describing itself and collects all the exported Hosts, then all managed nodes will end up with /etc/hosts files listing (at least) all managed nodes.

 

I think the word "node" was tripping me up in the online documentation -- I was reading "node" and thinking "resource". Okay, I get it now, and you're absolutely right -- this is a terrible use of exported resources. I think what I was looking for was virtual, not exported, resources.

No, I think you were just looking for collections.  You can use them with ordinary (non-virtual) resources.  If you are not already using virtual resources to manage the Yum repos then I don't see what advantage you would obtain by converting your ordinary resources to virtual ones.


John

[Bret Wortman]

I think you're right. Thanks, John and Ken for helping get me straightened out.

Bret Wortman

http://about.me/wortmanbret

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8f851721-c4f2-44e8-97ad-5e68afd8581d%40googlegroups.com.