Skip to content

fix: handle default priority class and remote SA#1088

Open
sambuc wants to merge 3 commits intomainfrom
fix-allow-the-creation-of-a-default-priority-class-and-a-remote-service-account
Open

fix: handle default priority class and remote SA#1088
sambuc wants to merge 3 commits intomainfrom
fix-allow-the-creation-of-a-default-priority-class-and-a-remote-service-account

Conversation

@sambuc
Copy link
Copy Markdown
Contributor

@sambuc sambuc commented Mar 13, 2026

Add flags to create:

  • a default resource quota priority class for renku user sessions
  • a service account with a role and role binding to allow a remote renku portal to manage Amalthea sessions.

@sambuc sambuc requested review from a team and olevski as code owners March 13, 2026 14:17
sambuc added a commit to SwissDataScienceCenter/renku that referenced this pull request Mar 13, 2026
comments about priority class and the service account, tied to SwissDataScienceCenter/amalthea#1088
Copy link
Copy Markdown
Member

@olevski olevski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Lionel we should discuss this. I am pretty sure we just don need any of the changes in here. In the worst case if we do need something we can document and ask admins to create them manually on the remote cluster outside of a helm chart.

metadata:
labels:
app: renku
name: renku-user-sessions-priority
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is never referenced in the source code of amalthea. Why is it part of the helm chart? Amalthea does not make or manage priority classes.

apiVersion: v1
kind: ServiceAccount
metadata:
name: renku-remote-session-manager
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This service account is not used anywhere in amalthea? Why have it here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is the same "service account name" used in the cluster spec on the data service then that is used to assign a specific service account to the user session that is created. And in almost all cases the sessions do not need a dedicated service account. The only place we have needed this is on openshift where a dedicated service account is used to get a different security context constraint.

@aledegano
Copy link
Copy Markdown
Contributor

Hey Lionel we should discuss this. I am pretty sure we just don need any of the changes in here. In the worst case if we do need something we can document and ask admins to create them manually on the remote cluster outside of a helm chart.

Hey Tasko, I can give some context here: I have asked Lionel to add some of these manifests after I did the exercise of deploying on a Switch Cloud Kaas cluster (although the provider doesn't matter).
I was following the instructions that he wrote and remarking that there are a bit too many manual/out-of-band operations that should -if possible- be brought back into the chart.

Perhaps we could make everyone happy by having a toggle for this chart to select if it's deployed alongside Renku or as an agent/remote-operator?

olevski pushed a commit to SwissDataScienceCenter/renku that referenced this pull request Mar 20, 2026
comments about priority class and the service account, tied to SwissDataScienceCenter/amalthea#1088
@sambuc
Copy link
Copy Markdown
Contributor Author

sambuc commented Mar 30, 2026

I made the deployment of these two things based on conditions which are set to false by default.

The idea is that when an admin is OK with using the default value, they just set the conditions they want to true, or leave it as false, and create by hand the associated resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants