Open esraneufeld opened 2 years ago
To avoid overscheduling of nodes, services should be scheduled with minimal resource requirements. In order not to limit "power users", those requirements can be dynamically be overwritten by users via the osparc user interface. Possibility to override is tied to users/group permissions. (computational backend for now, also keep in mind ITISFoundation/osparc-issues#576)
@mguidon, could something be done this sprint to prevent the case MS was hitting see this message in Mattermost? For the POs this is still very important and needed for s4l upcoming releases. Could you please discuss with the backend team and see what can be done?
Hi. Strictly speaking, personalized resources are not required for s4l:web:lite. Melanies problem is related to her using a very outdated legacy service (with strict resource limits of outrageous 96 GB RAM) and her needing more RAM than the default one for the newer version (16GB).
If we want to work on that I suggest to do a minimal thing that allows us to override the limits but not yet the users. (e.g. enhancing the services_specifications
table in the db.)
@sanderegg @GitHK any thoughts on this?
Write down in details how this will be surfaced to the users
Potential first use case: Melanie can choose how much RAM the ti jupyter smash has available. Default will be what is on the label. If the admin allows it, she can individually change the settings upon starting of the service.
Use-case:
after discussion with @mguidon the idea is to go with 1. first and wait with 2. until capabilities of dynamic clusters are better defined. 3. could be implemented once 1. is done.
Done:
Summary: The user can now change a service required resources (CPUs, RAM) through the oSparc GUI. These changes are persisted within the project. There are currently no upper bound for resources. The platform will try to start the service using the defined required resources.
Open:
To avoid overscheduling of nodes, services should be scheduled with minimal resource requirements. In order not to limit "power users", those requirements can be dynamically be overwritten by users via the osparc user interface. Possibility to override is tied to users/group permissions. (computational backend for now, also keep in mind https://github.com/ITISFoundation/osparc-issues/issues/576)