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
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/997d02b2-82bd-42af-8a3d-01522a4ee72f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> 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 puppet-users+unsubscribe@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.
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 On Thu, Nov 21, 2013 at 10:53 AM, Ken Barber <ken@puppetlabs.com> wrote:> > 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 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+unsubscribe@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. >-- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAN9oxgRT_1amgPh63yqSNDbBQ1fGrGUP2QHxG7nfMK8sx34zgw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 <ken@puppetlabs.com> wrote:> > 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 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+unsubscribe@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. >-- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAN9oxgStxTjcA6ef7cq%2BCwouXFpso5hCgKkOWDq44qiHRnZK2A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 On Thu, Nov 21, 2013 at 11:15 AM, Bret Wortman <bret@thewortmans.org> wrote:> 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 <ken@puppetlabs.com> wrote: > >> > 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 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+unsubscribe@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. >> > >-- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAN9oxgRFQYL5eOs8XE%2BMBmjje0mv7%3DJgJJBACipwarA%3Dk4y2%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 -- 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+unsubscribe@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. For more options, visit https://groups.google.com/groups/opt_out.
I think you''re right. Thanks, John and Ken for helping get me straightened out. *Bret Wortman* http://about.me/wortmanbret On Thu, Nov 21, 2013 at 1:52 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > 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 > > -- > 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+unsubscribe@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 > . > > For more options, visit https://groups.google.com/groups/opt_out. >-- 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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAN9oxgS-JRyOCr%2BLFQmvEMQxgbh6LkHr0mT4UFo9Wbm5tsCy-w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.