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
The environment variables configured there are problematic:
the logic to determine the secret's name should be located on one single place, in the helpers function, where it is already. Actually, when submitting [DB] Fix builtin DB init script. Document the DB existingSecret params #51, i missed this one and in some cases, it is faulty (is using builtin DB but providing existing secret, this does not resolve properly)
if someone decides not to use datafeeder or a geodata DB, the env vars won't be resolved and the geoserver pod will fail to start
The idea of geOrchestra being to be as modular as possible and keep a loose coupling when possible, I believe that those env vars should not be configured in the deployment template. They are necessary only for configuring the JNDI connectors, which are optional and defined outside of the chart. Geodata DB is optional too. And so is the datafeeder.
I am proposing to move the declaration of those env vars into extra_environment section for the geoserver container. This would work very well, make it easier to configure/modify JNDI behaviour and above all easier to see and figure out. And allow people to not configure this or do it differently.
The text was updated successfully, but these errors were encountered:
The environment variables configured there are problematic:
The idea of geOrchestra being to be as modular as possible and keep a loose coupling when possible, I believe that those env vars should not be configured in the deployment template. They are necessary only for configuring the JNDI connectors, which are optional and defined outside of the chart. Geodata DB is optional too. And so is the datafeeder.
I am proposing to move the declaration of those env vars into
extra_environment
section for the geoserver container. This would work very well, make it easier to configure/modify JNDI behaviour and above all easier to see and figure out. And allow people to not configure this or do it differently.The text was updated successfully, but these errors were encountered: