Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

Can you undo the change in foreman, see if the problem goes away, then
reimplement the change and see if the problem comes back? That would go a
long way toward isolating the cause.

On Thursday, October 6, 2016,  wrote:

>
>
> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu
>  wrote:
>>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following
>> error off and on (not consistently) across many nodes on a puppet update
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER:
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
>> on node "
>>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all)
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g.
>> mine-yumconfig). After upgrading the unrelated module, again many nodes
>> with this issue will now have it resolved, and different ones not
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: http://grokbase.com/t
>> /gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by
>> something that varies between runs. That could be almost anything:
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate
>> class in your module." However, in my case, I did not write the saz-rsyslog
>> module, I am only using it. It is a puppet-forge approved module with
>> 635,000+ downloads. And without modifying the module, the issue can
>> disappear, seemingly without rhyme or reason.
>>
>> -RG
>>
>
>
> Some more information
>
> I am using the latest version of the saz-rsyslog puppet module, version
> 4.0.3
> https://forge.puppet.com/saz/rsyslog
>
> As an example, I have this node called h1pa
> Yesterday afternoon this node was getting the reported duplicate
> Class[Rsyslog] declaration error
> The 12:15am update was the last report of this error
> The 12:45am update was the first clean update today
> In fact, I had 0 nodes reporting this error
>
> About 9:00am-ish we added a subnet and hostgroup to The Foreman. However
> we have not added any new nodes, nor changed the configuration to any
> existing nodes.
>
> Then, I started getting the error again
> The 9:15am update was the first report of this error this late morning
> The 9:45am update reported this error again
> My nodes reporting an error of this duplicate Class[Rsyslog] error
> increased from 0 to 12.
>
> All node reports with this error are similar to h1pa node's reports.
> I am seeing that many of the hosts experiencing this issue yesterday, are
> now experiencing it again.
>
> -RG
>
>
>
>
>
>
>
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC76iT-PtvNQvFt2rp6YKrX_wMNuCMQLsgVrxHig3pxCEWf1Lg%40mail.gmail.com.
For more options, visit 

[Puppet Users] Re: Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu wrote:
>
> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet via 
> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the following 
> error off and on (not consistently) across many nodes on a puppet update 
> (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
> on node "
>
>
> My nodes are CentOS 5,6,7; and any various number of the nodes may 
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes not 
> having this issue. This may go on for days if I do not touch The Foreman.
> I'll make some changes to host configuration for puppet module class 
> parameters in The Foreman - never the saz-rsyslog module though..
> After the changes, half or more of the servers having issue (not all) will 
> magically have no problems.
> However, more nodes that did not have issues before, will now experience 
> this issue.
>
> Also, this change of events is not directly related to The Foreman host 
> configuration changes.
> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
> mine-yumconfig). After upgrading the unrelated module, again many nodes 
> with this issue will now have it resolved, and different ones not 
> experiencing the issue before will now begin experiencing it.
>
>
> The only clue I have is from this posting: 
> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
> "... If you do not see the error on every run then it is modulated by 
> something that varies between runs. That could be almost anything: 
> manifests, data, results of function calls, node facts, or ENC output. ..."
>
>
> Can anyone help me understand this issue, or help me get it resolved 
> permanently?
>
> When I search for answers, all I see are "You have written a duplicate 
> class in your module." However, in my case, I did not write the saz-rsyslog 
> module, I am only using it. It is a puppet-forge approved module with 
> 635,000+ downloads. And without modifying the module, the issue can 
> disappear, seemingly without rhyme or reason.
>
> -RG
>


Some more information

I am using the latest version of the saz-rsyslog puppet module, version 
4.0.3
https://forge.puppet.com/saz/rsyslog

As an example, I have this node called h1pa
Yesterday afternoon this node was getting the reported duplicate 
Class[Rsyslog] declaration error
The 12:15am update was the last report of this error 
The 12:45am update was the first clean update today
In fact, I had 0 nodes reporting this error

About 9:00am-ish we added a subnet and hostgroup to The Foreman. However we 
have not added any new nodes, nor changed the configuration to any existing 
nodes.

Then, I started getting the error again
The 9:15am update was the first report of this error this late morning
The 9:45am update reported this error again
My nodes reporting an error of this duplicate Class[Rsyslog] error 
increased from 0 to 12.

All node reports with this error are similar to h1pa node's reports.
I am seeing that many of the hosts experiencing this issue yesterday, are 
now experiencing it again.

-RG






 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Thursday, October 6, 2016 at 8:27:40 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu wrote:
>>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via 
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following 
>> error off and on (not consistently) across many nodes on a puppet update 
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
>> on node "
>>
>>
>
> It seems highly unlikely that merely installing the module on the master 
> would cause any catalog compilations to fail, and certainly the error 
> message indicates that there are some declarations of its classes in play.  
> It is not the mere presence of the module, but rather the declarations of 
> one or more classes in it that is causing you trouble.
>
>  
>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may 
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not 
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class 
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all) 
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience 
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host 
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
>> mine-yumconfig). After upgrading the unrelated module, again many nodes 
>> with this issue will now have it resolved, and different ones not 
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: 
>> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by 
>> something that varies between runs. That could be almost anything: 
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved 
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate 
>> class in your module."
>>
>
>
> Any such claim is at best misleading.  The problem is not that you or 
> anyone has written a duplicate class, it's that the class in question has 
> been *declared* more than once, and at least one of those declarations 
> uses the resource-like style.  In considering that, you should be aware 
> that:
>
>- a declaration in resource-like style can include one emitted by your 
>ENC (part of Foreman) if it uses the form that specifies class parameters 
>explicitly, and
>- when one class inherits from another, any declaration of the derived 
>class comprises an implicit declaration of its base class.  Furthermore,
>- when class inheritance is involved, the docs 
>
>  
>specify that any parameters of the base class must either take their 
>default values or have their values supplied by automatic external data 
>lookup.  In practice, that's too weak -- a separate resource-like 
>declaration of the base class can cause trouble even if it specifies no 
>parameter values.
>
> I talked up class inheritance because I've examined the manifests of the 
> latest version of the module, and there are indeed a few cases of class 
> inheritance that could be feeding your problem.  There are also cases of 
> ordinary declaration of class ::rsyslog by other classes in that module.  
> The bottom line is that you need to follow the advice from the docs with 
> respect to class ::rsyslog by avoiding declaring it via the resource-like 
> style, including preventing your ENC from doing so.  Any non-default 
> parameters must be provided via automated data binding.  I'm afraid I'm not 
> knowledgeable enough about The Foreman to tell you how to handle that end, 
> however.
>
>
> John
>
>
I understand the duplicate declaration issue - I have been reading about it 
for months trying to figure out this issue that keeps popping up. I am 
trying to figure out how it is possible I am getting a duplicate class 
declaration on a widely-used and approved module I have no control over 
(that no one else has reported any similar issue as mine), when using the 
forman to simply provide the values of parameters.

Maybe The Foreman is the cause of the ::rsyslog class 

[Puppet Users] Re: Declare ressources from another stage

[Prunk Dump]

On Wednesday, October 5, 2016 at 4:15:21 PM UTC+2, jcbollinger wrote:
>
>
>
> On Tuesday, October 4, 2016 at 6:55:36 AM UTC-5, Prunk Dump wrote:
>>
>> Hello puppet users !
>>
>> My problem is simple. I use the following classes in three different 
>> stages (setup/main/runtime) :
>>
>> class { 'apt::client':
>>   stage => 'setup',
>> }
>> ...
>> ...
>> class { 'hostpkg': }
>> ...
>> ...
>> class { 'extrapkg':
>>   stage => 'runtime',
>> }
>>
>> The idea is that the "apt::client" class configure the Debian apt tools. 
>> Next the "hostpkg" class install and configure the important packages (ex: 
>> those needed to allow the connexion of users). And finally the "extrapkg" 
>> class install the secondary packages (internet browser etc ...). But 
>> sometimes the "hostpkg" or "extrapkg" packages need some extra apt sources, 
>> some apt-pinning or the multiarch. So I created three resources/class :
>>
>>
>
> Do take care to distinguish between operational relationships and 
> management relationships.  Puppet class and resource ordering is about 
> satisfying *management* relationships -- that is, situations where Puppet 
> can manage resource B only after first ensuring that resource A is in its 
> intended target state.  Avoid declaring unnecessary relationships, for 
> there is no upside at all to having such relationships, and it incurs added 
> risk of problems, such dependency cycles.  In particular, just because 
> package B uses or interacts with package A does not necessarily imply that 
> A must be managed before B, or vise versa.
>
> Especially take care with run stages, for they are nothing more than a 
> convenient mechanism to apply relationships to many pairs of classes at 
> once.  Almost inevitably they apply a lot of unneeded relationships, but 
> they may nevertheless be the best tool for a select few jobs.  Indeed, the 
> Puppet docs 
> 
>  
> say this:
>
> [...] *stages should only be used with the simplest of classes,* and only 
>> when absolutely necessary. Mass dependencies like package repositories are 
>> effectively the only valid use case.
>>
>
> I'm inclined to suppose that there may be other valid use cases at certain 
> sites, and I don't think the docs are saying that stages are always the 
> best solution for ensuring that package repositories are managed before all 
> packages, but do take the docs' remark in the spirit in which I think it 
> was intended: run stages are the wrong tool for almost every job.
>
> In your particular case, it may be that class apt::client is indeed one of 
> those rare classes that make sense in a non-default stage, but class 
> extrapkg seems very unlikely to be such a class.  In the unlikely event 
> that you need any puppet-application-ordering relationships between 
> resources declared in class extrapkg and (other) classes and resources in 
> stage main, I see no barrier to declaring those relationships explicitly.  
> Relying on doing so instead of needlessly placing class extrapkg in a 
> separate stage may solve some of your problems.
>
>  
>
>> define apt::client::pinning( $package = $title, $pin, $priority, $ensure 
>> = present)
>> define apt::client::source( $sourcename = $title, $type = 'deb', $uri, 
>> $distribution = $apt::client::distribution, $components, $ensure = present)
>> class apt::client::multiarch
>>
>> There three resources are contained in the "apt::client" class as they 
>> must be run before "apt-get update" (near "apt::client::end").
>>
>
>
> What resources?  I see (definitions of) two resource *types* and one 
> class.  Class apt::client may declare instances of the two types; those 
> *instances* are then contained by the class.  It might also declare and 
> even also contain (in the relationship sense) class apt::client::multiarch, 
> but the declaring and containing are separate considerations.  *Under no 
> circumstances*, however, should the *definitions* of these types and this 
> class be lexically contained within the definition of class apt::client.  
> Each definition should appear in its own file.
>
>  
>
>> The problem come when a package in "extrapkg" need for example the 
>> multiarch :
>>
>> -> From the "extrapkg" class I include the "apt::client::multiarch" class 
>> to get the multiarch activated
>>
>
>
> Ok.
>
>  
>
>> -> As the "extrapkg" class is in the "runtime" stage, the 
>> "apt::client::multiarch" is contained in the stage
>>
>
>
> Only if class extrapkg contains (relationship sense) class 
> apt::client::multiarch, unless I've missed a change somewhere.  Indeed, 
> lack of the behavior you describe was once cited as a bug, and that bug 
> report was rejected.
>
> If you do this ...
>
> # This should be ok:
> include "apt::client::multiarch"
>
> ... then you do not automatically put that class in the same run stage as 
> the class declaring it.  If, on the other hand, you ...
>
> # 

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Wednesday, October 5, 2016 at 3:58:38 PM UTC-5, Rob Nelson wrote:
>
> RG, typically the Duplication declaration message is followed by some 
> indicator of the file where it is duplicated and the line number. Are you 
> receiving that information and maybe snipped it off the end of the message 
> you included? An alternative might be any sort of `hiera_include()` or 
> `create_resources()` calls whose arguments may include `rsyslog` more than 
> once.
>
> Here is the complete output when running `puppet agent -t`:
[Linux ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
on node server1.mydomain.test1.example.com

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
[Linux ~]#



> Rob Nelson
> rnel...@gmail.com 
>
> On Wed, Oct 5, 2016 at 3:16 PM,  wrote:
>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via 
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following 
>> error off and on (not consistently) across many nodes on a puppet update 
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
>> on node "
>>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may 
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not 
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class 
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all) 
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience 
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host 
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
>> mine-yumconfig). After upgrading the unrelated module, again many nodes 
>> with this issue will now have it resolved, and different ones not 
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: 
>> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by 
>> something that varies between runs. That could be almost anything: 
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved 
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate 
>> class in your module." However, in my case, I did not write the saz-rsyslog 
>> module, I am only using it. It is a puppet-forge approved module with 
>> 635,000+ downloads. And without modifying the module, the issue can 
>> disappear, seemingly without rhyme or reason.
>>
>> -RG
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/1ead58c4-ed05-4b03-9bee-6fd576d187f3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3b067d75-df51-4a51-840e-d69990b592b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu wrote:
>
> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet via 
> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the following 
> error off and on (not consistently) across many nodes on a puppet update 
> (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
> on node "
>
>

It seems highly unlikely that merely installing the module on the master 
would cause any catalog compilations to fail, and certainly the error 
message indicates that there are some declarations of its classes in play.  
It is not the mere presence of the module, but rather the declarations of 
one or more classes in it that is causing you trouble.

 

>
> My nodes are CentOS 5,6,7; and any various number of the nodes may 
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes not 
> having this issue. This may go on for days if I do not touch The Foreman.
> I'll make some changes to host configuration for puppet module class 
> parameters in The Foreman - never the saz-rsyslog module though..
> After the changes, half or more of the servers having issue (not all) will 
> magically have no problems.
> However, more nodes that did not have issues before, will now experience 
> this issue.
>
> Also, this change of events is not directly related to The Foreman host 
> configuration changes.
> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
> mine-yumconfig). After upgrading the unrelated module, again many nodes 
> with this issue will now have it resolved, and different ones not 
> experiencing the issue before will now begin experiencing it.
>
>
> The only clue I have is from this posting: 
> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
> "... If you do not see the error on every run then it is modulated by 
> something that varies between runs. That could be almost anything: 
> manifests, data, results of function calls, node facts, or ENC output. ..."
>
>
> Can anyone help me understand this issue, or help me get it resolved 
> permanently?
>
> When I search for answers, all I see are "You have written a duplicate 
> class in your module."
>


Any such claim is at best misleading.  The problem is not that you or 
anyone has written a duplicate class, it's that the class in question has 
been *declared* more than once, and at least one of those declarations uses 
the resource-like style.  In considering that, you should be aware that:

   - a declaration in resource-like style can include one emitted by your 
   ENC (part of Foreman) if it uses the form that specifies class parameters 
   explicitly, and
   - when one class inherits from another, any declaration of the derived 
   class comprises an implicit declaration of its base class.  Furthermore,
   - when class inheritance is involved, the docs 
    
   specify that any parameters of the base class must either take their 
   default values or have their values supplied by automatic external data 
   lookup.  In practice, that's too weak -- a separate resource-like 
   declaration of the base class can cause trouble even if it specifies no 
   parameter values.
   
I talked up class inheritance because I've examined the manifests of the 
latest version of the module, and there are indeed a few cases of class 
inheritance that could be feeding your problem.  There are also cases of 
ordinary declaration of class ::rsyslog by other classes in that module.  
The bottom line is that you need to follow the advice from the docs with 
respect to class ::rsyslog by avoiding declaring it via the resource-like 
style, including preventing your ENC from doing so.  Any non-default 
parameters must be provided via automated data binding.  I'm afraid I'm not 
knowledgeable enough about The Foreman to tell you how to handle that end, 
however.


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a9d669b0-b043-4ec3-91b6-4667d08b9c1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[Erez Zarum]

It was just an example to reproduce it.

On Thursday, October 6, 2016 at 12:49:11 PM UTC+3, Rob Nelson wrote:
>
> I do not know that a workaround is needed. I believe that when a package 
> is upgraded, the old and new versions should show up in the logs already, 
> so the notify may not be needed.
>
> On Thursday, October 6, 2016, Erez Zarum  
> wrote:
>
>> Ok, so the workaround is to use a variable (set default), if that fails, 
>> try the fact.
>>
>> Thanks!
>>
>> On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>>>
>>>
>>>
>>> - Original Message - 
>>> > From: "Erez Zarum"  
>>> > To: "puppet-users"  
>>> > Sent: Thursday, 6 October, 2016 09:40:44 
>>> > Subject: [Puppet Users] Facts and Resource relationships 
>>>
>>> > I'm not sure if it's a bug or an expected behavior. 
>>> > 
>>> > I have written a simple fact for a module that returns a version of a 
>>> > binary file, it executes: "binary --version" and then parses the 
>>> version, 
>>> > no issues there, it works. 
>>> > 
>>> > The issue i am having is relying on this fact in case the binary file 
>>> gets 
>>> > upgraded during a package installation (this is the simple example) 
>>> > 
>>> > package { 'package': 
>>> > ensure => '1.3.8' 
>>> > } -> 
>>> > notify { "version: ${::binary_version}": } 
>>> > 
>>> > If the previous version was 1.3.7 the fact "binary_version" will 
>>> return 
>>> > 1.3.7, the next run it will return 1.3.8 as expected. 
>>> > The biggest issue is if i rely on this fact to pick up a template to 
>>> use, 
>>> > if this package is not yet installed the fact won't work and will work 
>>> only 
>>> > on the second run. 
>>> > 
>>> > I can only assume this happens because the facts are being "compiled" 
>>> > before the catalog is. 
>>> > 
>>> > I have tried different ways to declare the relationship but it doesn't 
>>> work. 
>>>
>>> yes, you cant use facts for something that changes during a run.  It's 
>>> for facts 
>>> about your node that influence the creation of the catalog. 
>>>
>>> things the catalog changes - well thats after the catalog was created 
>>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> Rob Nelson
> rnel...@gmail.com 
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d1112795-2e3c-4552-ac9a-648d0f77eae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[Rob Nelson]

I do not know that a workaround is needed. I believe that when a package is
upgraded, the old and new versions should show up in the logs already, so
the notify may not be needed.

On Thursday, October 6, 2016, Erez Zarum  wrote:

> Ok, so the workaround is to use a variable (set default), if that fails,
> try the fact.
>
> Thanks!
>
> On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Erez Zarum" 
>> > To: "puppet-users" 
>> > Sent: Thursday, 6 October, 2016 09:40:44
>> > Subject: [Puppet Users] Facts and Resource relationships
>>
>> > I'm not sure if it's a bug or an expected behavior.
>> >
>> > I have written a simple fact for a module that returns a version of a
>> > binary file, it executes: "binary --version" and then parses the
>> version,
>> > no issues there, it works.
>> >
>> > The issue i am having is relying on this fact in case the binary file
>> gets
>> > upgraded during a package installation (this is the simple example)
>> >
>> > package { 'package':
>> > ensure => '1.3.8'
>> > } ->
>> > notify { "version: ${::binary_version}": }
>> >
>> > If the previous version was 1.3.7 the fact "binary_version" will return
>> > 1.3.7, the next run it will return 1.3.8 as expected.
>> > The biggest issue is if i rely on this fact to pick up a template to
>> use,
>> > if this package is not yet installed the fact won't work and will work
>> only
>> > on the second run.
>> >
>> > I can only assume this happens because the facts are being "compiled"
>> > before the catalog is.
>> >
>> > I have tried different ways to declare the relationship but it doesn't
>> work.
>>
>> yes, you cant use facts for something that changes during a run.  It's
>> for facts
>> about your node that influence the creation of the catalog.
>>
>> things the catalog changes - well thats after the catalog was created
>>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC76iT-UZyhicPbsmoF1CbTQiYQrhiPp8_PwCB5rHqmz%2Bsz17Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[Erez Zarum]

Ok, so the workaround is to use a variable (set default), if that fails, 
try the fact.

Thanks!

On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>
>
>
> - Original Message - 
> > From: "Erez Zarum"  
> > To: "puppet-users"  
> > Sent: Thursday, 6 October, 2016 09:40:44 
> > Subject: [Puppet Users] Facts and Resource relationships 
>
> > I'm not sure if it's a bug or an expected behavior. 
> > 
> > I have written a simple fact for a module that returns a version of a 
> > binary file, it executes: "binary --version" and then parses the 
> version, 
> > no issues there, it works. 
> > 
> > The issue i am having is relying on this fact in case the binary file 
> gets 
> > upgraded during a package installation (this is the simple example) 
> > 
> > package { 'package': 
> > ensure => '1.3.8' 
> > } -> 
> > notify { "version: ${::binary_version}": } 
> > 
> > If the previous version was 1.3.7 the fact "binary_version" will return 
> > 1.3.7, the next run it will return 1.3.8 as expected. 
> > The biggest issue is if i rely on this fact to pick up a template to 
> use, 
> > if this package is not yet installed the fact won't work and will work 
> only 
> > on the second run. 
> > 
> > I can only assume this happens because the facts are being "compiled" 
> > before the catalog is. 
> > 
> > I have tried different ways to declare the relationship but it doesn't 
> work. 
>
> yes, you cant use facts for something that changes during a run.  It's for 
> facts 
> about your node that influence the creation of the catalog. 
>
> things the catalog changes - well thats after the catalog was created 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[R.I.Pienaar]

- Original Message -
> From: "Erez Zarum" 
> To: "puppet-users" 
> Sent: Thursday, 6 October, 2016 09:40:44
> Subject: [Puppet Users] Facts and Resource relationships

> I'm not sure if it's a bug or an expected behavior.
> 
> I have written a simple fact for a module that returns a version of a
> binary file, it executes: "binary --version" and then parses the version,
> no issues there, it works.
> 
> The issue i am having is relying on this fact in case the binary file gets
> upgraded during a package installation (this is the simple example)
> 
> package { 'package':
> ensure => '1.3.8'
> } ->
> notify { "version: ${::binary_version}": }
> 
> If the previous version was 1.3.7 the fact "binary_version" will return
> 1.3.7, the next run it will return 1.3.8 as expected.
> The biggest issue is if i rely on this fact to pick up a template to use,
> if this package is not yet installed the fact won't work and will work only
> on the second run.
> 
> I can only assume this happens because the facts are being "compiled"
> before the catalog is.
> 
> I have tried different ways to declare the relationship but it doesn't work.

yes, you cant use facts for something that changes during a run.  It's for facts
about your node that influence the creation of the catalog.

things the catalog changes - well thats after the catalog was created

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/685981672.59634.1475739920045.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Facts and Resource relationships

[Erez Zarum]

I'm not sure if it's a bug or an expected behavior.

I have written a simple fact for a module that returns a version of a 
binary file, it executes: "binary --version" and then parses the version, 
no issues there, it works.

The issue i am having is relying on this fact in case the binary file gets 
upgraded during a package installation (this is the simple example)

package { 'package':
 ensure => '1.3.8'
} ->
notify { "version: ${::binary_version}": }

If the previous version was 1.3.7 the fact "binary_version" will return 
1.3.7, the next run it will return 1.3.8 as expected.
The biggest issue is if i rely on this fact to pick up a template to use, 
if this package is not yet installed the fact won't work and will work only 
on the second run.

I can only assume this happens because the facts are being "compiled" 
before the catalog is.

I have tried different ways to declare the relationship but it doesn't work.





-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ca95130b-51b2-4d33-8919-a3977615ed25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.