✨ catalog: adds services compatibility policy 🗃️

[pcrespov]

What do these changes do?

Uses version specifiers clauses (e.g. ~=0.9, >=1.0, !=1.3.4.*, <2.0) to define version ranges for compatibility policies. This provides rules to determine, given a service:X.Y.Z, a range of compatible versions from which the latest is returned as can_update_to. This is then usedin the front-end to update to the "latest compatible version".

Hightlights

• 🎨 Default compatibility policy upgrades to the latest patch, i.e. latest(>X.Y.Z, ~=X.Y.Z).
• ✨ Service owners can customize the compatibility policy
  • between versions: Service A:X.Y.Z is compatible with service A:$versions_specifier
  • across service keys: Service A:X.Y.Z is compatible with service B:$versions_specifier
  • 🗃️ A new services_compatibility table to serialize customization (otherwise defaults policy).
• Web API: Compatibility is returned in all history entries, both in
  - Listing (temporarily to monitor performance)
  - GET operations.

Related issue/s

• Implements compatibility in Front-end uses new catalog/services/* web API entrypoint #5964

How to test

• Driving test

cd services/catalog
make install-dev
pytest -vv tests/unit/test_services_compatibility.py

• Manual test using swagger /dev/catalog/services/* entrypoints
• Set services_compatibility row with custom rules for simcore/services/comp/itis/sleeper:1.0.0
  
  
  From the image

1. custom policy applies: upgrades to a different service key/version
2. default patch-upgrade policy
3. cannot upgrade o anything since it is the latest version

Dev-ops checklist

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

[codecov]

Codecov Report

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

Project coverage is 88.0%. Comparing base (cafbf96) to head (aca1d90).
Report is 360 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #6071      +/-   ##
=========================================
+ Coverage    84.5%   88.0%    +3.4%     
=========================================
  Files          10    1267    +1257     
  Lines         214   53376   +53162     
  Branches       25     732     +707     
=========================================
+ Hits          181   46983   +46802     
- Misses         23    6230    +6207     
- Partials       10     163     +153     

Flag	Coverage Δ
integrationtests	60.5% <ø> (?)
unittests	86.5% <91.4%> (+1.9%)	⬆️

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

Files	Coverage Δ
...src/models_library/api_schemas_catalog/services.py	100.0% <100.0%> (ø)
...els-library/src/models_library/services_history.py	100.0% <100.0%> (ø)
...e/src/simcore_postgres_database/models/services.py	100.0% <ø> (ø)
...postgres_database/models/services_compatibility.py	100.0% <100.0%> (ø)
...e_service_catalog/db/repositories/_services_sql.py	100.0% <100.0%> (ø)
...s/catalog/src/simcore_service_catalog/db/tables.py	100.0% <100.0%> (ø)
.../src/simcore_service_catalog/models/services_db.py	100.0% <100.0%> (ø)
...c/simcore_service_catalog/services/services_api.py	79.3% <100.0%> (ø)
...se/src/simcore_postgres_database/models/_common.py	95.0% <75.0%> (ø)
.../simcore_service_catalog/services/compatibility.py	97.6% <97.6%> (ø)
... and 1 more

... and 1229 files with indirect coverage changes

[odeimaiz]

I've seen it working, nice 👌

[mguidon]

Very very good. Thank you. One thing that comes to mind (but in the case of sim4life it might anyhow not work) Can you deduce the inverse dependency chain? i.e. can the frontend deduce how to downgrade from one version to another across different keys?

[pcrespov]

Very very good. Thank you. One thing that comes to mind (but in the case of sim4life it might anyhow not work) Can you deduce the inverse dependency chain? i.e. can the frontend deduce how to downgrade from one version to another across different keys?

@mguidon @odeimaiz the reverse operation is one-to-many. A way forward would be that when a service is upgraded, we keep the changes history (similar to do/undo functionatliy). Perhaps a service in a project could keep that in a special entry.

[bisgaard-itis]

Very cool! Thanks a lot for the effort

[GitHK]

Please consider my two comments.

[matusdrobuliak66]

Cool, thanks!