Maintenance: adjust the labels set on all services to follow inversed url notation

[sanderegg]

Currently the services/container run as service have the following hard-coded labels:

• user_id
• study_id
• uuid (= node_id)

These should be replaced by (also NOTE that _ are not recommended by docker for keys)

• io.simcore.service.user-id
• io.simcore.service.study-id (or project-id)
• io.simcore.service.node-id

There is code ready to be used for this in
services/autoscaling/src/simcore_service_autoscaling/models.py

with function to read from a Task and generate the dict[str,str] as well.

Tasks

Beta Give feedback

1. add cpu/memory limits to dy-sidecar user-services and computational services
2. Review of the labels necessary at least for dy-sidecar/dy-proxy
3. Define proper label naming following Docker recommendations (e.g. no _ but -) and allows to diff between image labels (e.g. static labels), container labels and service labels (e.g. runtime labels)
4. make use of DockerLabelKey pydantic model to ensure we are using Docker compatible keys
5. ensure consistency by using the same models
6. ✨ Computational backend: set container limits as labels ⚠️ (devops checks on grafana dashboards!) 🚨 #4453
   a:director-v2 a:models-library a:webserver +3
   

[pcrespov]

Please consider the logic for image labels (denoted "labels annotations" by OCI stds) to/from pydantic models developed in

https://github.com/ITISFoundation/osparc-simcore/blob/master/packages/service-integration/src/service_integration/labels_annotations.py (see tests and other modules in library for usage xamples)

There is also a good quality logic there to validate all metadata in images.

[sanderegg]

Current situation on the docker labels

reminder:

• Docker recommends not to use _ in the docker label keys (not sure about kubernetes)
• Docker recommends to use inverse url notation

legacy dynamic services

These tables describe the labels added onto the running services.

label name	service labels	comments
uuid	node id
study_id	project id
swarm_stack_name	master-simcore	useful for multi-deploy on same platform
user_id	user id
port	the port to access the service	necessary for legacy services
type	main	used for multi-containers services
traefik.*	all traefik proxy settings
io.simcore.zone	relates to traefik

label name	container labels	comments
mem_limit	bytes
nano_cpu_limit	nano cpus
node_id	node id	fun it is not using uuid here...
simcore_user_agent	puppeteer or undefined	used to filter e2e runs
study_id	project id
swarm_stack_name	master-simcore
user_id	user id
image.labels	all the docker image labels

dy-sidecar services

dy-sidecar

here the labels sub-divide between the dynamic-sidecar service, the dy-proxy service and the user-services

label name	service labels	comments
io.simcore.scheduler-data	huge json
key	service key
port		any use ?
service_image	dynamic sidecar docker image name
service_port		twice?? any use?
study_id	project id
swarm_stack_name	master-simcore
type	main-v2	why v2?
user_id	user id
uuid	node id
version	service version	any use?

label name	container labels
mem_limit	bytes
nano_cpu_limit	nano cpus
uuid	node id
study_id	project id
user_id	user id
image.labels	all the docker image labels

dy-proxy

label name	service labels
dynamic_type	dynamic-sidecar
io.simcore.zone	traefik related
study_id	project id
swarm_stack_name	master-simcore
traefik.*	traefik related
type	dependency-v2
user_id	user id
uuid	node id

label name	container labels
uuid	node id
study_id	project id
user_id	user id
image.labels	all the docker image labels

user-services

label name	container labels
product_name	osparc
simcore_user_agent	puppeteer or undefined
study_id	project id
user_id	user id
uuid	node id
image.labels	all the docker image labels

computational services

label name	container labels
product_name	osparc
simcore_user_agent	puppeteer or undefined
study_id	project id
user_id	user id
uuid	node id
image.labels	all the docker image labels

[sanderegg]

From above:

• legacy services are missing the product_name, and they use node_id instead of uuid
• dynamic-sidecar services seem to be very inconsistent in how labels are set (at least for dy-sidecar,dy-proxy), also using v2 for no apparent reason. some labels are maybe useless?
• dynamic-sidecar user-services are now on par with computational services that were missing the information,
• both are now missing the cpu/memory limit labels

[sanderegg]

Docker image labels

• io.simcore.authors, io.simcore.inputs, ... these are the docker image labels defined since the beginning of times
• org.label.schema-, ... these are the docker image labels following the (also old) docker image standard
• simcore.service.path-mappings, simcore.service., .... these are the docker image labels used by osparc to run services (ideally should have been io.simcore. as well ;()

Proposal for docker service/container labels

• io.simcore.service.runtime.node-id
• io.simcore.session.node-id
• io.simcore.runtime.node-id

[GitHK]

dynamic-sidecar

label name	service labels	comments	replies
port		any use ?	not sure about this one, guess it can be dropped
service_port		twice?? any use?	this is the port where the user services will be exposed
type	main-v2	why v2?	@pcrespov let's ask him why this was introduced, I missed this one, there is also an wired outdated comment here form me
version	service version	any use?	current service version, useful for debugging

[mrnicegyu11]

Thanks for this very verbose summary, I am absolutely in favor of doing a cleanup here :)

I have checked our grafana dashbaords and it seems the only label we really use is simcore_user_agent, everything else we filter based on image names or other "hacks" that do not depend on the other mentioned labels.

TL;DR: green light from my side, if you change things here we will address any minor issues once they pop up :)

[matusdrobuliak66]

@sanderegg For resource tracking/billing purposes as discussed we will start with scraping the sidecars (the benefit of this is that when the service consists of more sub-services, where the user can set up all the resources, we have all the information there. The disadvantage is that we have problems with hanging sidecars - but we can address them + we will have the second data source from director-v2). Also, we would like to store the AWS instance type on which the service is running.

1. I think currently we are not able to query Prometheus on combination dy-sidecar + service (such as sim4life), we should add some identification to the labels for that?
2. Regarding instance type, maybe we can have some instance type mapping table in the backend and based on it also inject it as a label?