Comments (4)
After a second deeper look it seems there is not much that can be done reasonably in HULL itself to overcome the issue(s).
The main somewhat related problems seem to be:
- integer type information is lost from the YAML input when it gets processed in Helm so all integers seem to become
float64
for internal processing - large numbers > 1.000.000 are represented as
float64
in scientific notation when they are being refered to - with or without being wrapped as a string in the first place - strings ending with regex
e\d+$
are interpreted asfloat64
in scientific notation by Helm - with or without being wrapped as a string in the first place
Looking at 1., the original type is already lost when starting to work with the values so it is impossible to automatically apply workarounds to treat everything correctly in the process. Something like 1e+07
could have been integer 1000000
or float 1000000.0
originally (which you'll never know) and guessing and auto-magical conversions when processing seem kind of dangerous. Taking 2. into consideration, it gets worse because not only is the value in the string interpeted as a number, it is converted to float64
and represented in scientifc notation.
The simple and convenient - yet mostly sufficient - _HT*
to reference the value does not suffice here and you need to apply one of the various workarounds mentioned in the issue threads. You can achieve this putting the workaround code in a full-fleged _HT!
transformation.
The following is tested with helm version=3.13.3
-
To reference a value that is unquoted integer and potentially > 1.000.000 you can use this transformation where you need the target value as an big integer:
_HT!{{ (index . "$").Values.hull.config.specific.potentiallyLargeInteger | int64 }}
For example, if
potentiallyLargeInteger
is123456789
this will produce123456789
without any quotes. -
To reference a value that is unquoted integer and potentially > 1.000.000 you can use this transformation where you need the target value as a string:
_HT!{{ (index . "$").Values.hull.config.specific.potentiallyLargeInteger | int64 | quote }}
For example, if
potentiallyLargeInteger
is123456789
this will produce"123456789"
with quotes.You need to use this if you are creating the value of an env var, an annotation or label or image tag and are expecting this kind of input!
-
To reference a value that is string and potentially an integer > 1.000.000 or potentially matches the scientific notation regex
e\d+$
you can use this transformation where the target value is a string:_HT!{{ (index . "$").Values.hull.config.specific.gitCommit | toJson | trimAll "\"" | quote }}
For example, if
gitCommit
is"123456789"
this will produce"123456789"
or ifgitCommit
is"11724e28"
this will produce"11724e28"
.You always need to use quotation marks around the input value, otherwise it may be interpreted as a number in scientific notation by which the wanted string representation is forever gone
The above mentioned and in my opinion best workarounds I took from here.
To conclude, I think you should try using the following code to cover all bases since the commit hash may both resemble large integers > 1.000.000 or a general number in scientific notation:
hull:
config:
general:
metadata:
labels:
common:
revision: _HT!{{ (index . "$").Values.hull.config.specific.tag | toJson | trimAll "\"" | quote }}
specific:
tag: "3964137"
objects:
deployment:
server:
pod:
containers:
api:
image:
registry: us.gcr.io
repository: my-app/my-api
tag: _HT!{{ (index . "$").Values.hull.config.specific.tag | toJson | trimAll "\"" | quote }}
Sorry it is that ugly and unintuitive, can't do much about the original problem :(
Hope what I wrote above is correct and proposed solution works for you, if not let me know!
from hull.
Hi @seniorquico,
thank you for using HULL and your report!
Unfortunately you have hit a hornets nest here. This is a general Helm problem (or I suppose more of a Go problem) and not specific to HULL, It pops up whenever you have an integer number which is greater than 1.000.000 wrapped in a string. Internally it converts the big int into a float64 and produces the dreaded scientific notation. So in your case - if the stars align badly - it is the commit hash being all numbers.
There are many threads about it, this matches your use case I think exactly. But there are lots of other reports of this such as this , this and this with the mother of all threads on the subject being this one having a display of 93 comments (think it is way more though) and 60 users involved. It started in 2016 and is still - from my point of view - open. There are a couple of workarounds mentioned here which may be applicable in your case,
Actually I have hit this too at some point when trying to reference a large number > 1.000.000 in a chart and putting it into an env var. I was similarily surprised to find this is a well known issue and yet unresolved in a proper fashion. When I found it I tried to do some magic in the inner code of HULL to get around it but it seemed hard to impossible since basically the very last toString
call always messed it up and produced scientific notation. I dropped the topic back then due to limited time and it not being critical for us in this specific case. Nevertheless it left me quite unsatisfied at the time.
I will try to come up with a suggestion of applying one of the workarounds to your nice example, thanks for that. Or maybe I take another stab at it to solve it in an acceptable way in HULL. Even though it is not HULL's problem I would certainly like HULL to not stumble over it and offer some advantage over plain Helm if possible.
from hull.
@seniorquico Happy new year to you ;)
Are you satisfied with the explanations above? If so let me know, if not please also let me know.
Will leave this open for a couple of days hoping to hear from you before closing,
Thanks!
from hull.
Yes, I understand the limitations. I'll give this workaround a try the next time this problem occurs. Thanks for the follow-up!
from hull.
Related Issues (20)
- Bug: Ingress with TLS HOT 4
- Using transformations in objects' names HOT 2
- Empty list in hull.util.transformation.include HOT 8
- Generating properties with transformations HOT 2
- Using transformations in hull.objects.secret.*.data.*.inline HOT 13
- Something is wrong when using a transformation in hull.objects.ingress.*.tls.*.hosts HOT 3
- The hull.util.transformation.makefullname transformation and and the staticName parameter HOT 9
- Creating non-opaque Secrets HOT 6
- hull.util.transformation.get converts a string to an integer HOT 3
- Empty fields in rendered template HOT 5
- Accessing the global context from an interpolation placeholder HOT 7
- Is there an idiomatic way to access Chart and Release objects HOT 7
- Add more single valued functions to `_HT*` transformations HOT 1
- Add `sharedContainers` feature
- Enable array access in `_HT*` HOT 1
- Default security settings
- [question] Is it possible to create ConfigMap from a directory using glob pattern ? HOT 20
- Cronjob jobspec not mapping several fields HOT 2
- Combine boolean evaluation `_HT?` with get `_HT*` and include `_HT/` transformations HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hull.