-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add function to parse canonical quantities (e.g. resources) #855
add function to parse canonical quantities (e.g. resources) #855
Conversation
c7d8a03
to
b2d1dfa
Compare
I don't think the test failures are related to my change |
/assign test failure is unrelated #795 (comment) |
b2d1dfa
to
8895fcf
Compare
rebased on master, tests are succeeding now |
any chance for a review? |
8895fcf
to
43d25be
Compare
rebased |
LGTM in general. I'm also concerned about the floating number output which might defeat the purpose of the canonical quantity which guarantees no precision lost given it's on client side and currently only in parsing canonical quantities (instead of writing), perhaps it's okay to use floating numbers /approve |
@yliaog can you take a look when you get a moment? |
import re | ||
|
||
|
||
def parse_quantity(quantity): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes this function currently only parse the canonical form of the quantities, which is what you get in the api objects. It is not intended to re-implement the quantities in kubernetes.
it is probably reasonably straightforward to do by returning decimal objects instead of floats.
Imo that is not unreasonable, but it means user have to work fully in decimals or convert to float/integer as you cannot mix both in computations.
Should I change it to decimals and be able to parse all number representations, also those that will never be in api objects?
e5b3e6a
to
e825f56
Compare
Updated to use Decimal as output, add more testcases and added nano(n) and micro(u) which is apparently supported by Quantities (but not listed in its documentation) |
|
||
def parse_quantity(quantity): | ||
""" | ||
Parse kubernetes canonical form quantity like 200Mi to a decimal number. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add a link to the quantity code in k/k repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
This utility function is useful to parse values like the 200m or 300Gi memory and cpu resources stored in kubernetes manifests. It uses Decimal as output format as it usually represents typical input values more accurately and reduces rounding errors.
e825f56
to
8b385a8
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: juliantaylor, roycaihw, yliaog The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This utility function is useful to parse values like the 200m or 300Gi
memory and cpu resources stored in kubernetes manifests.
The function only supports the "canonical form" which has no fractional
digits.
Currently no support for negative numbers as those to my knowledge don't appear in manifests, though it could be added for completeness.
A concern is the return value of the function, currently it is a float.
Though maybe a Decimal would be better as that represents the intention of the number somewhat better (exact representation for typically used numbers, typically arithmetic is more exact etc.) but using a somewhat rarely used type as a return value could have unforeseen consequences elsewhere (.e.g. type float checks would fail, other libraries may not support decimals properly etc.)