You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Authorino reads configuration for the executable from environment variables. This is not ideal as env vars usually belong to the global state of the operating system and, most importantly, are mutable. We should follow a better practice and read configuration options from command-line arguments instead.
@guicassolato this caught my eye - just wondering if this implies that authorino can never pick up configuration changes at runtime ?
i.e. would I always need to restart pods for config changes to be picked up ? are there cases where the application logic would need to handle a certain config param's value transition ?
just wondering if this implies that authorino can never pick up configuration changes at runtime
@gsaslis, this is true for things as they are today already. Authorino reads env vars at boot-time and then works with those values all along.
So what we gain here with this issue is not really predictability about the execution itself, but rather the ability to read the state of the application as of when it was booted in the first place. By reading the env vars on the other hand, you know the current values, but not the original ones (at least not from within the environment).
One could argue that in a containerised world, env vars are (should be) immutable and you should always redeploy the application when you want to modify the environment, like for example by editing a Deployment resource in Kubernetes. However, if that is true, then so is your original statement all the same. Authorino never picks up configuration changes at runtime.
That all been said, what I did not say about this issue before is that it also has to do with:
improving the command-line for the application – something we did for Limitador already (CLI limitador#92);
standardising the way boot options are passed to the application – today there's a mix of env vars and command-line args.
As final thoughts, I would add that, for inter-process communication, there are better ways to exchange data than by modifying the global state of environment; while for intra-process using env vars is an indication of bad design IMO.
All the freedom we deserve, but just as much so we don't hurt ourselves! 🙂
Authorino reads configuration for the executable from environment variables. This is not ideal as env vars usually belong to the global state of the operating system and, most importantly, are mutable. We should follow a better practice and read configuration options from command-line arguments instead.
This will require changes in https://github.com/kuadrant/authorino-operator as well.
The text was updated successfully, but these errors were encountered: