♻️ reroute user services restart via dynamic-scheduler

[GitHK]

What do these changes do?

Rerouted user services restart command via dynamic-scheduler.

Related issue/s

• dynamic scheduler: extract scheduling logic and move it away from director-v2 #5632
• requirement: reroute director-v2 service calls via dynamic-scheduler from webserver #6894
• closes redirect service_restart_containers call via dynamic-scheduler #6944

How to test

Dev-ops checklist

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

[codecov]

Codecov Report

Attention: Patch coverage is 72.00000% with 7 lines in your changes missing coverage. Please review.

Project coverage is 86.93%. Comparing base (acd677a) to head (4e397da).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6943      +/-   ##
==========================================
- Coverage   87.06%   86.93%   -0.14%     
==========================================
  Files        1611     1256     -355     
  Lines       63621    53925    -9696     
  Branches     2026     1001    -1025     
==========================================
- Hits        55392    46880    -8512     
+ Misses       7895     6851    -1044     
+ Partials      334      194     -140     

Flag	Coverage Δ
integrationtests	64.91% <50.00%> (-2.07%)	⬇️
unittests	85.25% <72.00%> (-0.10%)	⬇️

Components	Coverage Δ
api	∅ <ø> (∅)
pkg_aws_library	∅ <ø> (∅)
pkg_dask_task_models_library	∅ <ø> (∅)
pkg_models_library	∅ <ø> (∅)
pkg_notifications_library	∅ <ø> (∅)
pkg_postgres_database	∅ <ø> (∅)
pkg_service_integration	∅ <ø> (∅)
pkg_service_library	74.14% <0.00%> (-0.06%)	⬇️
pkg_settings_library	∅ <ø> (∅)
pkg_simcore_sdk	85.38% <ø> (ø)
agent	96.82% <ø> (ø)
api_server	90.13% <ø> (ø)
autoscaling	96.09% <ø> (ø)
catalog	90.57% <ø> (ø)
clusters_keeper	99.48% <ø> (ø)
dask_sidecar	91.26% <ø> (ø)
datcore_adapter	93.18% <ø> (ø)
director	76.40% <ø> (ø)
director_v2	91.43% <ø> (ø)
dynamic_scheduler	97.14% <100.00%> (+0.04%)	⬆️
dynamic_sidecar	89.75% <ø> (ø)
efs_guardian	90.12% <ø> (ø)
invitations	93.44% <ø> (ø)
osparc_gateway_server	∅ <ø> (∅)
payments	92.66% <ø> (ø)
resource_usage_tracker	89.58% <ø> (+0.26%)	⬆️
storage	89.54% <ø> (ø)
webclient	∅ <ø> (∅)
webserver	84.46% <50.00%> (+0.06%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update acd677a...4e397da. Read the comment docs.

[pcrespov]

So this PR basically replaces the first part of this long trace to "restart a user-service" bu adding a buffer (i.e. rabbit) and on extra service (dynamic_scheduler)

Before: (3 services)

• web-server ->(REST)-> director-v2 -> (REST) -> dynamic-sidecar -> (docker REST)

Now: (5 services)

• web-server -(RPC)->rabbitMQ -> (RPC) -> dynamic_scheduler ->(REST)-> director-v2 -> (REST) -> dynamic-sidecar -> (docker REST)

Probably i am missing something but besides the buffer (which i think is good) I do not totally understand the role of the dynamic-scheduler in there.

⚠️ This is a good example to check with opentelemetry tracing... and see the impact of this design decision :-) !

[GitHK]

So this PR basically replaces the first part of this long trace to "restart a user-service" bu adding a buffer (i.e. rabbit) and on extra service (dynamic_scheduler)

Before: (3 services)

• web-server ->(REST)-> director-v2 -> (REST) -> dynamic-sidecar -> (docker REST)

Now: (5 services)

• web-server -(RPC)->rabbitMQ -> (RPC) -> dynamic_scheduler ->(REST)-> director-v2 -> (REST) -> dynamic-sidecar -> (docker REST)

Probably i am missing something but besides the buffer (which i think is good) I do not totally understand the role of the dynamic-scheduler in there.

⚠️ This is a good example to check with opentelemetry tracing... and see the impact of this design decision :-) !

@pcrespov

There is one main reason for doing all this. In the context of moving away the dynamic scheduling logic form director-v2 (to the dynamic-scheduler), I'm trying to support two scheduling modes: via director-v2 and via dynamic-scheduler.

To achieve it, there needs to be a point of switching. The dynamic-scheduler, in this case, which decides which scheduler to use.

Another advantage is that in the end all scheduling logic will be placed inside the dynamic-scheduler and we are already rerouting all the calls from webserver to dynamic-scheduler in the context of dynamic services (only).

So it's required now and also in the future. Which is why I'm doing all this refactoring.

[pcrespov]

thx for the explanation.

[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 SonarQube Cloud