Hi Clay,
On Fri, Apr 1, 2016 at 1:57 PM, Clay Caviness <c...@boobah.com> wrote:
> I've come across an issue with facter 3, when using at_exit. Basically,
> any at_exit blocks that refer to anything not in the top-level namespace
> (pardon my terminology) trigger an 'uninitialized constant' NameError. I
> think this is a namespace issue of some sort, but it's beyond my ken.
>
> To recreate:
> Create uninitialized.rb:
> require 'facter'
> at_exit { Facter.warn('Facter.warn at exit') }
> at_exit { puts 'puts at exit' }
> Facter.add('uninitialized_constant') do
> setcode do
> 'foo'
> end
> end
>
> Run facter:
> facter -p uninitialized_constant facterversion
> facterversion => 3.1.4
> uninitialized_constant => foo
> puts at exit
> /private/var/puppet/lib/facter/unint.rb:3:in `block in <top (required)>':
> uninitialized constant Facter (NameError)
>
> Note that the 'puts' at_exit works, but not the one using Facter.warn.
>
This is caused by how custom facts are resolved in Facter 3: namely that
custom facts are resolved all at once and no further calls from Ruby into
Facter's native implementation are expected when all resolutions have
completed. The Facter module removes itself from the Ruby runtime after
all resolutions complete, but before the Ruby runtime is shutdown (when
at_exit callbacks would occur). This is why your at_exit callbacks can't
find the Facter module; it's no longer there at that point.
Looking things over, I believe it doesn't need to be implemented this way.
The Facter module could outlive the Ruby runtime, allowing at_exit
callbacks to still make use of Facter. This would require that the native
implementation not attempt to clean up explicit GC registrations made from
the module, which should be entirely unnecessary anyway since the Ruby
runtime has (in theory at least) destroyed the GC heap when the Ruby
runtime is shutdown.
I haven't seen at_exit used in a custom fact before, so I'm interested in
your use case. Given that I consider this behavior to be an implementation
bug in Facter, would you mind opening a JIRA ticket at
https://tickets.puppetlabs.com (project should be "FACT" for Facter) and
detailing the use case?
Thanks!
>
> This works fine in facter 2:
> $ sudo facter -p uninitialized_constant facterversion
> facterversion => 2.4.4
> uninitialized_constant => foo
> puts at exit
> Facter.warn at exit
>
> I've put all this up at
> https://gist.github.com/ccaviness/12b1db78c42283f4193a1709dd03a8ac
>
> --
> 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/CANU2HrfPkoYcZcEWUioiTbyeN-60KfceZx3d1UX5XzdL3atSqg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CANU2HrfPkoYcZcEWUioiTbyeN-60KfceZx3d1UX5XzdL3atSqg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CACZQQfNc01%2ByZBEOeDHTdbES5qVv8uiqQmnpB9sqSbRhE7zTRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
