✨ Auto inject osparc environments to dynamic services

[pcrespov]

What do these changes do?

Injects automatically

environment:
    OSPARC_API_BASE_URL: "$OSPARC_VARIABLE_API_HOST"
    OSPARC_API_KEY: "$OSPARC_VARIABLE_API_KEY"
    OSPARC_API_SECRET: "$OSPARC_VARIABLE_API_SECRET"
    OSPARC_NODE_ID: "$OSPARC_VARIABLE_NODE_ID"
    OSPARC_STUDY_ID: "$OSPARC_VARIABLE_STUDY_UUID"

to all services in a dynamic-service compose. I.e. all dynamic services get automatically access to these environs. NOTE that the key/secrets are customised per user.

@sanderegg @mguidon should we only inject in the "main" service, i.e. the one specified by simcore.service.container-http-entrypoint?

Related issue/s

• resolves Pass oSparc API necessary environment to all services #5925

How to test

• driving tests services/director-v2/tests/unit/test_modules_osparc_variables.py
• Manual testing:
  • Open jupyter (or any other dynamic service).
  • printenv | sort | grep OSPARC_ and check that all the env-vars above are defined
    

Dev-ops checklist

• No ENV changes or I properly updated ENV (read the instruction)

[codecov]

Codecov Report

Attention: Patch coverage is 93.75000% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.5%. Comparing base (cafbf96) to head (eb42cc4).
Report is 290 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #5966      +/-   ##
=========================================
+ Coverage    84.5%   88.5%    +3.9%     
=========================================
  Files          10    1053    +1043     
  Lines         214   46585   +46371     
  Branches       25     562     +537     
=========================================
+ Hits          181   41248   +41067     
- Misses         23    5214    +5191     
- Partials       10     123     +113     

Flag	Coverage Δ
integrationtests	65.5% <91.6%> (?)
unittests	86.1% <87.5%> (+1.5%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...rary/src/models_library/service_settings_labels.py	91.8% <100.0%> (ø)
...v2/modules/dynamic_sidecar/docker_compose_specs.py	97.9% <100.0%> (ø)
...ector_v2/modules/osparc_variables/substitutions.py	74.2% <90.9%> (ø)

... and 1044 files with indirect coverage changes

[sanderegg]

that is very nice! thanks!
Now regarding your question, I think for example in s4l the variables are probably needed in the core service which I do not think is the main one. but @mguidon can enlighten us

[pcrespov]

that is very nice! thanks! Now regarding your question, I think for example in s4l the variables are probably needed in the core service which I do not think is the main one. but @mguidon can enlighten us

If that is the case, I do not have the info to know which service is "the core" service

[elisabettai]

Very nice, thanks!

Minor thought on the name of the variable OSPARC_NODE_ID: I guess in the code you normally say "node" and this word is mostly used by devs. For user-facing docs, etc... we tend to use more "Service".
But I assume users who will use this envs are enough dev-oriented to understand what that variable represent. 😉

[pcrespov]

Very nice, thanks!

Minor thought on the name of the variable OSPARC_NODE_ID: I guess in the code you normally say "node" and this word is mostly used by devs. For user-facing docs, etc... we tend to use more "Service". But I assume users who will use this envs are enough dev-oriented to understand what that variable represent. 😉

@elisabettai Unfortunately this is already decided and used in the client side. Can you perhaps follow up with a small entry in the manual at some time? Not urgent

[bisgaard-itis]

Very cool! Thanks a lot