Sim4Life-Web dy-service versioning

[SCA-ZMT]

Conclusions from the working group

• All s4l-based services get identical version numbers
  • sim4life
  • isolve
  • JupyterLab
  • python runner
• For now, version numbers will be 8.0.0, 8.0.1, 8.0.2. This requires the Desktop Versioning to be changed because the web will release more often
• The services will be named sim4life 8.0 (next minor release sim4life 8.2) and user will be able to select patch versions
• We will buffer the latest official desktop version and the latest patch
• The Dashboard in the services tab will show all versions similar to the Tutorials in a list with headers: 8.0. 8.2, 9.0
• Since the service key will change from 8.0 to 8.2 we need to improve the updating mechanism in the frontend (first example will be moving from current lite to lite 8.0)

---

Event Horizon

Preview Give feedback

1. Can use tags in services and list services grouped by tags osparc-simcore#6202
   2 of 5
   a:catalog a:frontend a:webserver +3
   
2. Backend: Share Tags #1808
   +0
   
3. Frontend: Share Tags #1809
   +0
   

Tasks

Preview Give feedback

No tasks being tracked yet.

Eisbock

Preview Give feedback

1. Alias for services in catalog osparc-simcore#2521
   a:catalog a:frontend t:enhancement +3
   
2. Release a new Sim4Life.Lite version #1419
   +0
   
3. Release 8.0.2 on sim4life.io/.science #1420
   +0
   
4. More control over service metadata osparc-simcore#5476
   1 of 1
   a:catalog t:enhancement +2
   
5. Prettify marked.js' outcome #1704
   a:frontend +1
   

Tom Bombadil

Preview Give feedback

1. Front-end uses new catalog/services/* web API entrypoint osparc-simcore#5964
   11 of 11
   +0
   
2. monorepo/ooil #1426
   +0
   
3. Script to rename service key in a deploy osparc-simcore#6068
   +0
   

Leeroy Jenkins

Preview Give feedback

1. Updates cookie-cutter to incorporate new metadata fields in the template cookiecutter-osparc-service#113
   enhancement +1
   
2. ✨♻️ New version_display and release_date fields for service metadata osparc-simcore#5902
   a:models-library a:ooil +2
   
3. ♻️🎨 ooil config init to create first.osparc config layout osparc-simcore#5913
   a:ooil +1
   

[mguidon]

After discussion with @eofli, we do not need to group the services by version. They can all got into one service. That reduces the problem to making services compatible among minor and major versions and among service keys.

[drniiken]

As discussed in the pre-planning, we need a good "DEFINITION OF DONE" for this case.
We/Team can maybe have a chat later this week or next week.
Thx, best, Nik

[pcrespov]

[mguidon]

As discussed, merging of the tiles will not be done programatically but through retagging/labeling of the corresponding (entrypoint-) images. This requires:

• Retag all isolve, jupyter-smash, s4l-python-runners and sim4life master services that are listed in the registry-syncer config (lets first check if tag and "key" label is enough (I dont think we need the "compose-spec" as well)
• Update the list of images to sync
• For all key:version pairs above copy all entries in the following tables:
  • resource_tracker_pricing_plan_to_service
  • services_access_rights
  • services_specifications
  • services_vendor_secrets
  • `user_preferences_user_service (I think this one can safely be omitted)
• Finally, update the following table:
  • services_compatibility

@pcrespov I guess the db part is trivial to script once we are sure the list above is complete?

[pcrespov]

MartinKippenberger Sprint

completed

• 🐛 Fixes duplicates in tags listings and new priority to enforce order  osparc-simcore#6479
• Discussed design of tags sharing and policies on how to deal with tags that are part of a shared project

open

• Complete implementation of the API to share tags
• Complete implementation of tags in services
• List services grouped by tags
• Improve performance of service entrypoints (new features made entrypoints again slow!)