🎨Autoscaling: Add option to allow a new node to join a cluster directly active (🚨 ⚠️ DEVOPS)

[sanderegg]

What do these changes do?

This PR adds the option for a node to join the swarm as directly active, as it seems to be more time efficient.
Since it needs to be tested in real conditions, this is for now by default not set.

Adds AUTOSCALING_DOCKER_JOIN_DRAINED ENV var that allows to make a new node directly join as an active node, potentially speeding up docker swarm mechanics (to be tested)
Adds AUTOSCALING_WAIT_FOR_CLOUD_INIT_BEFORE_WARM_BUFFER_ACTIVATION ENV var that skips waiting for Warm buffer cloud initialization (in direct testing brought a 20% speed up)

Related issue/s

How to test

Dev-ops checklist

• No ENV changes or I properly updated ENV (read the instruction)
• related MR: https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/merge_requests/863
• related MR: https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/merge_requests/864

[codecov]

Codecov Report

Attention: Patch coverage is 63.63636% with 8 lines in your changes missing coverage. Please review.

Project coverage is 88.1%. Comparing base (cafbf96) to head (815b6a7).
Report is 521 commits behind head on master.

Files with missing lines	Patch %	Lines
...e_service_autoscaling/modules/auto_scaling_core.py	33.3%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #6334      +/-   ##
=========================================
+ Coverage    84.5%   88.1%    +3.5%     
=========================================
  Files          10    1499    +1489     
  Lines         214   62062   +61848     
  Branches       25    2065    +2040     
=========================================
+ Hits          181   54707   +54526     
- Misses         23    7039    +7016     
- Partials       10     316     +306     

Flag	Coverage Δ
integrationtests	63.4% <ø> (?)
unittests	86.2% <63.6%> (+1.6%)	⬆️

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

Files with missing lines	Coverage Δ
...aling/src/simcore_service_autoscaling/constants.py	100.0% <100.0%> (ø)
...g/src/simcore_service_autoscaling/core/settings.py	100.0% <100.0%> (ø)
...e_autoscaling/modules/buffer_machines_pool_core.py	88.4% <100.0%> (ø)
...ore_service_autoscaling/utils/auto_scaling_core.py	93.6% <100.0%> (ø)
.../simcore_service_autoscaling/utils/utils_docker.py	100.0% <100.0%> (ø)
...e_service_autoscaling/modules/auto_scaling_core.py	91.3% <33.3%> (ø)

... and 1442 files with indirect coverage changes

[pcrespov]

thx

Q: I understand that this PR introduces the ability to "reuse" nodes that are currently active. In cases where nodes have been previously utilized, is there a risk that residual data or processes from prior services could impact the new services? Alternatively, can you confirm that the machine will operate in a "clean" state, as if newly provisioned?

[sanderegg]

thx

Q: I understand that this PR introduces the ability to "reuse" nodes that are currently active. In cases where nodes have been previously utilized, is there a risk that residual data or processes from prior services could impact the new services? Alternatively, can you confirm that the machine will operate in a "clean" state, as if newly provisioned?

No, when a machine is created, it runs a docker swarm join --availability=drain to connect with the swarm.
This PR allows to change the --availability flag to "active" or "drain" depending if it is False or True

[matusdrobuliak66]

👍

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud