+26
−29
+28
−21
Loading
The template still supports the old input, reverted to the behavior from before the change done by Domenic. For everybody, except escape, the change should be transparent, but old behavior is not documented anymore. The old behavior is considered deprecated and will be removed in a major release after announcing it to communities. The new method of configuring the fts renewal job is much more explicit. Requiring to manually mount secrets into the container using the "secretMounts" (formally additionalSecrets), and passing directly ENV variables required by whatever script is selected. While this may seem as a downgrade in terms of usability, I would argue it's much better this way. The old behavior had 2 major problems: - the user had to manually create, prior to running helm, secrets with very specific names. Which somebody could know only by looking at the source code of the helm chart. The work done by Domenic improved the situation, but made the following issue worse: - the helm template is full of if/else which basically require per-vo specific configuration anyway. And the main way to know how to make that work was, obviously, to read the source code of both the helm chart and the container scripts. This change decouples the "VO", from the script it uses to renew certificates. This is important, because it should allow support for multi-vo in the future and avoid duplicating the scripts (for ex: the one from escape is basically a copy of the default script) To support the new "script" argument, a small change will be needed in the containers repository to pick the script based on this value rather than using the RUCIO_VO env variable. The commit also prepares the path for multi-vo configurations. "vos" is now a list instead of being a string as before. And each vo name+voms are exported via a separate env variable to the containers. For reverse compatibility with existing scripts, the first VO in the list is (also) exported via RUCIO_VO env var. The commit also mounts the rucio configuration from the helm "values.config" into the pod. While it's not required now, this may allow, in the future, to change the behavior of the fts renewal script based on rucio configuration. This could probably be used for multi-vo, where each vo could have a specific configuration.