New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 [BUG]: Regression handling DATA_PERSIST_ROOT
setting
#270
Comments
In this case, I can only see 2 solutions: 1- keep 2- remove In all cases we can document that to "move" I have a préférence for option 2, what do you guys think? |
From these propositions, I personally prefer option 1 over 2 (though not optimal) because it preserves the original behavior (before the bug was introduced). The current changes unexpectedly broke my setup, and I don't want this to happen every time a new variable is added. Users should not have to worry about always adding new variables to support new features, as it makes feature integration and migration harder for them. When adding new variables, omitting them should preserve the original behavior. I do not like the symlink fix approach. The target I have 2 possible alternative solutions to propose: using a
|
…ot take effect and warn when a dir in `EXTRA_CONF_DIRS` does not exist (#272) ## Fixes: - Overriding `DATA_PERSIST_ROOT` in `env.local` do not take effect for `JUPYTERHUB_USER_DATA_DIR`, `MAGPIE_PERSIST_DIR`, and `GEOSERVER_DATA_DIR`. These 3 vars will have to be delayed evaluated for override in `env.local` to take effect. For a variable to be delayed evaluated, it has to be defined using single-quote and be added to the list of `DELAYED_EVAL` in `default.env`. If those steps are forgotten in `env.local`, it will still work since `env.local` is the last file to be read. However those steps should not be forgotten in any `default.env` for all components. So the impact or burden is on the developpers to write their `default.env` file properly, not on the users that only modify the `env.local` file. All `default.env` files header have been updated with notice about this new delayed evaluation feature. Fixes #270 ## Changes: - Warn when a dir in `EXTRA_CONF_DIRS` does not exist. Most likely a typo in a new dir. Just warn and not exit directly to avoid leaving the entire platform down during an unattended autodeploy since no one is around to take immediate action. Fixes #266
Summary
Regression in handling
DATA_PERSIST_ROOT
setting does not produce the intended effect if anything other than defaults are used.Details
Regression introduced in d4f2f44 regarding the use of
DATA_PERSIST_ROOT
.New variable
MAGPIE_PERSIST_DIR
(there might be others doing similar things in other commits [?] )have been defined indefault.env
making use of the (up to that point) default value ofDATA_PERSIST_ROOT=/data
.If the user defined instead their own
DATA_PERSIST_ROOT
in theenv.local
for an alternate storage location, all those derived variables do not consider the new value because they are already set.This produces inconsistent directory storage locations and does not respect the expected behavior defined by the user.
To Reproduce
Steps to reproduce the behavior:
DATA_PERSIST_ROOT=/my-data
pavics-compose up -d
The volumes that make direct reference to
${DATA_PERSIST_ROOT}
indocker-compose,yml
(and component overrides) will have the correct path.When using derived directory variables, they will still be under
/data/...
.Environment
DATA_PERSIST_ROOT
with another valueDATA_PERSIST_ROOT
and no explicitMAGPIE_PERSIST_DIR
Concerned Organizations
@matprov @tlvu
The text was updated successfully, but these errors were encountered: