Puppet users - Jan 2013 - Fact chicken and egg problem

I am trying to expose a custom fact that requires a certain gem to be 
installed.  However, the facts are being loaded before the module is loaded 
(and I see why this is the case sine the fact should be made available to 
the module).  So my question is, is there a way to avoid this chicken and 
egg problem?  I tried putting the module in a stage before main, but it 
still looks like the facts are loaded first.

Thanks!
Birch

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/sv5dB5_KGVQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tuesday, January 22, 2013 12:13:32 PM UTC-6, James Birchfield
wrote:
>
> I am trying to expose a custom fact that requires a certain gem to be 
> installed.  However, the facts are being loaded before the module is loaded
> (and I see why this is the case sine the fact should be made available to 
> the module).  So my question is, is there a way to avoid this chicken and 
> egg problem?  I tried putting the module in a stage before main, but it 
> still looks like the facts are loaded first.


Facts are evaluated first, and sent to the master as part of the request 
for a catalog.  The whole catalog is compiled based on those facts, and 
returned to the client for the agent to apply.  Run stages affect only the 
order in which resources in the catalog are applied to the client.

It seems to me that the best approach is for your custom fact 
implementation to recover gracefully from the needed gem being absent, and 
for either the value of that fact or of a separate one to in that case 
indicate the absence of the gem.  You might in that case take no action 
based on the fact value, except to ensure the needed gem installed.

Alternatively, it may be that what you are trying to do in your custom fact 
would be better positioned as part of a provider for a resource type, or 
else used in some way by the body of a defined type.

Or maybe there''s a different way to get the information you want that 
doesn''t depend on software you cannot safely assume to be available.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/D4eaMoQGBRIJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thank you for the reply.  I decided to go with the approach of gracefully 
handling the fact that the require will fail from the fact and report it, 
thus allowing the RPM to be installed correctly.  Then the fact will 
populate on a subsequent run.

Birch

On Tuesday, January 22, 2013 3:18:12 PM UTC-5, jcbollinger
wrote:
>
>
>
> On Tuesday, January 22, 2013 12:13:32 PM UTC-6, James Birchfield wrote:
>>
>> I am trying to expose a custom fact that requires a certain gem to be 
>> installed.  However, the facts are being loaded before the module is
loaded
>> (and I see why this is the case sine the fact should be made available
to
>> the module).  So my question is, is there a way to avoid this chicken
and
>> egg problem?  I tried putting the module in a stage before main, but it
>> still looks like the facts are loaded first.
>
>
>
> Facts are evaluated first, and sent to the master as part of the request 
> for a catalog.  The whole catalog is compiled based on those facts, and 
> returned to the client for the agent to apply.  Run stages affect only the 
> order in which resources in the catalog are applied to the client.
>
> It seems to me that the best approach is for your custom fact 
> implementation to recover gracefully from the needed gem being absent, and 
> for either the value of that fact or of a separate one to in that case 
> indicate the absence of the gem.  You might in that case take no action 
> based on the fact value, except to ensure the needed gem installed.
>
> Alternatively, it may be that what you are trying to do in your custom 
> fact would be better positioned as part of a provider for a resource type, 
> or else used in some way by the body of a defined type.
>
> Or maybe there''s a different way to get the information you want
that
> doesn''t depend on software you cannot safely assume to be
available.
>
>
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/RWiyqZshUX0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.