date:20170927

Jira (FACT-1732) Facter core dump on large integers

2017-09-27 Thread Branan Riley (JIRA)

Title: Message Title

Branan Riley commented on FACT-1732

Re: Facter core dump on large integers

I definitely want to get this resolved ASAP if it's causing issues in the larger ecoystem. In the short term that probably stll means stringification, but longer-term I do want to be able to report large numbers correctly. Do the following steps seem reasonable to you?
1) Stringify everything suspicious. This means ruby bignums become strings on the way in to Facter, and anything greater than 2^53 becomes a string on the way out. This is probably overkill, but gets us to a solid baseline for consistent behavior and will avoid gross misbehaviors. (this is a refinement of what I proposed above, essentially).
2) Implement bignums internally. This will fix any numeric overflows in built-in facts (resolving disk sizes as negative, for example). This will also let us remove the stringification of Ruby values that are too large for 64-bit ints. We'll have to spend some time evaluating bignum libraries and getting our chosen one building across our supported platforms, so although this is a purely internal change, it's likely to be "effort", thus a step of its own.
3) Once we're sure the Puppet ecosystem can handle large integers, disable stringification at the output boundaries. At this point everything is correctly typed again, and we can pretend that none of this every happened. This will be a larger cross-team effort internally, and probably will involve some external documentation updates about what our various APIs accept/provide.
As for things like GCE IDs - we should be representing them as strings anyway. They may be made entirely of "digits", but they are logically single identifiers, not numbers. This is something we'll have to fix on a fact-by-fact basis, although turning large ints into strings at the various output boundaries should avoid compatibility issues in the medium term.
If you haven't already, can you file tickets against puppetdb and puppetserver with the issues you've seen in those projects? I will want to round up with the appropriate folks internally in order to develop a larger "bignum plan", and having tickets for the failure cases will make that much easier.

Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

Jira (FACT-1732) Facter core dump on large integers

2017-09-27 Thread Trevor Vaughan (JIRA)

Title: Message Title

Trevor Vaughan commented on FACT-1732

Re: Facter core dump on large integers

Branan Riley To your point about disk sizes...the default mountpoints fact returns both available_bytes and size_bytes as Integers. The disks fact also returns size_bytes as an Integer.
If you have a representative disk with over 8 PB of space (not completely out of the question) then these facts will crash the system.
My previous math was wrong - Ruby's max hits 4 Exabytes which is stretching it for current technologies, but the _javascript_ limit of 2^53-1 is not.
Other items of note (default Facter)

gce.instance.id => 4073115147758271314 (no idea how this is not crashing things, perhaps the hash burial is saving it)

gce.project.numericProjectId => 1064768239454 (no idea how big this might get)

My point is that you just don't know what any of this is going to be.

Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

60 matches

Mail list logo