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.
Reasonably Related Threads
- chicken/egg between pipefs and initramfs/hotplug
- EC2 bootstrap: chicken and egg problem with login as ec2-user and sudoers "requiretty"
- Chicken and egg question: passwd and cronjob
- Chicken-and-egg problem with domain SID
- chicken/egg problem with custom types