This PR drafts new entrypoints for the web-api for catalog/services collection. Specifically
These entrypoints have been redesigned to:
reduce the amount of items in the responses
include service history (i.e all version)
resolve version compatibility
NOTE: these entrypoints are only available with WEBSERVER_DEV_FEATURES_ENABLED=1, i.e. only available in master for testing.
Hightlights
⚗️ Drafts new API to list, get and update a service
list operation only returns only latest versions of each service (in contrast to the previous implementation that returned every single version). This already will drastically reduce the amount of items listed.
list includes pagination
To get the information of other versions, the new model includes a history field with with all the releases of the service.
history also includes information on version compatibility that will now be resolved in the backend. Therefore, given a service,
the latest compatible version is found under history[*].compatibility.can_update_to
the latest version of that service is history[0]
♻️ Organized service_metadata_... model variants
🔨 increase test coverage of labels_annotations module
What do these changes do?
This PR drafts new entrypoints for the web-api for
catalog/services
collection. SpecificallyThese entrypoints have been redesigned to:
NOTE: these entrypoints are only available with
WEBSERVER_DEV_FEATURES_ENABLED=1
, i.e. only available in master for testing.Hightlights
history
field with with all the releases of the service.history
also includes information on version compatibility that will now be resolved in the backend. Therefore, given a service,history[*].compatibility.can_update_to
history[0]
service_metadata_...
model variantsRelated issue/s
services/web/server/tests/unit/with_dbs/01/test_catalog_handlers__services.py
How to test
dev
entrypoints. They provide fake data but it is consistent with new modelsDev-ops checklist
None