✨ web-api: Adds endpoint to retrieve project services with Release and Access Information

[pcrespov]

What do these changes do?

The objective is to introduce an end-point in the web API that, given a project, retrieves all its services along with release and access-rights information. This would enable the front-end to:

• Determine the number of services within that project.
• Check access rights for execution and identify the owner if access is restricted.
• Assess whether a service is active, deprecated, or retired.
• Identify if a newer compatible version is available for an upgrade.

✨ web-server osparc service:

• services/webserver api version: 0.60.0 → 0.61.0
  • New GET /projects/{project_id}/nodes/-/services in projects rest controller
• New function in project node's repository to get node's services in a project
• New function in catalog service to batch-get services from catalog osparc-service (via RPC interface described in next section)

✨ catalog osparc service:

• New batch-get operation for services:

  • Implements the service layer: batch_get_my_services.
  • Adds an RPC controller for batch retrieval.

• Deprecation of the history field in service listings:

  • The history field is now marked as deprecated in service listings.
  • Only the get-service operation will provide history details.

Next steps

• @odeimaiz will adapt the front-end to use new entrypoint and avoid history field in listing
• @pcrespov will drop then history field from services listing
• at this point the user UX to start the app will be much faster

Related issue/s

• part of Optimization and wrap-up of catalog services web-api #6201

How to test

Driving tests

cd services/web/server
make install-dev
pytest -vv tests/unit/with_dbs/02/test_projects_nodes_handlers__services_access.py

cd services/catalog
make install-dev
pytest -vv tests/unit/with_dbs

Manual testing

• a study with many services
  
• using swagger
  

Dev-ops

None

[codecov]

Codecov Report

Attention: Patch coverage is 91.07143% with 15 lines in your changes missing coverage. Please review.

Project coverage is 87.18%. Comparing base (a059026) to head (a7f864a).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7287      +/-   ##
==========================================
+ Coverage   86.78%   87.18%   +0.40%     
==========================================
  Files        1518     1693     +175     
  Lines       60431    65772    +5341     
  Branches      884     1121     +237     
==========================================
+ Hits        52445    57344    +4899     
- Misses       7719     8108     +389     
- Partials      267      320      +53     

Flag	Coverage Δ
integrationtests	65.37% <64.28%> (+0.02%)	⬆️
unittests	86.34% <91.07%> (+0.48%)	⬆️

Components	Coverage Δ
api	76.84% <ø> (ø)
pkg_aws_library	94.24% <ø> (ø)
pkg_dask_task_models_library	97.09% <ø> (ø)
pkg_models_library	91.62% <100.00%> (∅)
pkg_notifications_library	84.57% <ø> (ø)
pkg_postgres_database	88.28% <ø> (ø)
pkg_service_integration	70.03% <ø> (ø)
pkg_service_library	72.48% <0.00%> (-0.13%)	⬇️
pkg_settings_library	90.61% <ø> (ø)
pkg_simcore_sdk	85.46% <ø> (ø)
agent	96.46% <ø> (ø)
api_server	90.68% <ø> (ø)
autoscaling	96.08% <ø> (ø)
catalog	92.10% <96.61%> (+0.37%)	⬆️
clusters_keeper	99.24% <ø> (ø)
dask_sidecar	91.25% <ø> (ø)
datcore_adapter	98.06% <ø> (ø)
director	76.68% <ø> (+0.09%)	⬆️
director_v2	91.30% <ø> (ø)
dynamic_scheduler	97.33% <ø> (ø)
dynamic_sidecar	90.28% <ø> (ø)
efs_guardian	90.25% <ø> (ø)
invitations	93.28% <ø> (ø)
osparc_gateway_server	∅ <ø> (∅)
payments	92.66% <ø> (ø)
resource_usage_tracker	89.11% <ø> (+0.10%)	⬆️
storage	84.43% <ø> (+0.19%)	⬆️
webclient	∅ <ø> (∅)
webserver	85.31% <100.00%> (+0.01%)	⬆️

---

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 a059026...a7f864a. Read the comment docs.

[GitHK]

I made a bit of a mess with the review comments. sorry for that.

[sanderegg]

Thanks! hoping this makes it fast!
I am not convinced by replacing list by batch_get I find the first one much more clear. but whatever.

[pcrespov]

Thanks! hoping this makes it fast! I am not convinced by replacing list by batch_get I find the first one much more clear. but whatever.

@sanderegg I think there is a misunderstanding.The design change isn't just about replacing the service list with batch-get. The core idea is to fetch only what’s needed, when it’s needed.

Before: All service details were included in the service listing.
Now: The service listing contains only essential information (i.e. no history), and when we need details about services in a project, we use a dedicated entry point to retrieve them.

In any case, none of this will have a real effect until the logic in the front-end is modified.

[odeimaiz]

Very nice, thanks :)

[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