I definitely want to embrace some features that have been released more recently
@QuantEnabler it’s technically possible to create a custom build of InfluxDB 1.x with a newer version of Flux, but AFAIK, the process is documented anywhere publicly. There are many features in Flux that have a direct tie to the InfluxDB storage engine that may or may not work with 1.8.
Out of curiosity, is there a reason you’re sticking with 1.8 and not upgrading to 2.x?
I assume you meant to say “…the process is NOT documented…”
I run oss 1.8 behind my own firewall, the apps that already push points via line protocol might take too much effort to add the additional token. Would not want to disrupt what is already very stable.
At some point I bite the bullet, but not high enough priority to version up to 2.n world
(even staging this takes a huge coordinated effort)
FLUX was supposed to even be independent of the tick stack when Paul preached about it in the early days. I have always had flux envy as the rapid enhancements far exceeded my ability to version up quickly.
Still a fan!
I assume you meant to say “…the process is NOT documented…”
Yes, you’re right. Sorry about that.
the apps that already push points via line protocol might take too much effort to add the additional token. Would not want to disrupt what is already very stable.
Gotcha. 2.x has a v1 compatible write API that lets you use the same write endpoint, but it does require some form of authentication (basic or token). If you’re not using authentication right now, you’d have to set it up which could be a significant amount of work.
thank you for the suggestion and additional comments. perhaps versioning up FLUX ahead of the full influxdb component or TICK stack might be a great blog or instructional video for your engineers.
even if it has some ‘gotchas’ it is a very powerful language and using the latest and greatest is always fun.
