Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve session pod labels #362

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

xai
Copy link
Contributor

@xai xai commented Oct 22, 2024

org.eclipse.theia.cloud.common.util.LabelsUtil is added to encapsulate creation of labels.

To indicate that a pod is a user session, its
'app.kubernetes.io/component' label is set to 'session'.

For custom labels, we use the prefix 'theia-cloud.io'.

This is currently used for:

  • Identifying a session pods associated with a user: 'theia-cloud.io/user' = '$username'
  • Identifying a session pod by appdefinition name: 'theia-cloud.io/app-definition' = $appdefinitionname

#366

org.eclipse.theia.cloud.common.util.LabelsUtil is added to encapsulate
creation of labels.

To indicate that a pod is a user session, its
'app.kubernetes.io/component' label is set to 'session'.

For custom labels, we use the prefix 'theia-cloud.io'.

This is currently used for:
- Identifying a session pods associated with a user:
  'theia-cloud.io/user' = '$username'
- Identifying a session pod by appdefinition name:
  'theia-cloud.io/app-definition' = $appdefinitionname

Signed-off-by: Olaf Lessenich <[email protected]>
Copy link
Contributor

@lucas-koehler lucas-koehler left a comment

Choose a reason for hiding this comment

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

Hi @xai ,
Thanks for this improvement :) Generally the changes look pretty good to me already. I have a few small remarks inline. Please have a look :)

Comment on lines +18 to +25
public static Map<String, String> createSessionLabels(SessionSpec sessionSpec, AppDefinitionSpec appDefinitionSpec) {
Map<String, String> labels = new HashMap<>();
labels.put(LABEL_KEY_SESSION, LABEL_VALUE_SESSION);
String userName = sessionSpec.getUser().split("@")[0];
labels.put(LABEL_KEY_USER, userName);
labels.put(LABEL_KEY_APPDEF, appDefinitionSpec.getName());
return labels;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

While we already add the app.kubernetes.io/component annotation, I think we should also add the app.kubernetes.io/part-of annotation with value theia-cloud.
This is helpful if Theia Cloud is installed together with other services in the same namespace. When we eventually apply this to all of Theia Cloud's components, this provides a selector to get everything related to Theia Cloud.

What do you think?

public static Map<String, String> createSessionLabels(SessionSpec sessionSpec, AppDefinitionSpec appDefinitionSpec) {
Map<String, String> labels = new HashMap<>();
labels.put(LABEL_KEY_SESSION, LABEL_VALUE_SESSION);
String userName = sessionSpec.getUser().split("@")[0];
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason we remove the second part of the email address (in case the user is an email address)? I would not do this because in deployments with a larger user base this can lead to collisions quite easily.

try {
client.services().inNamespace(client.namespace()).withName(serviceToUse.get().getMetadata().getName())
.edit(service -> {
LOGGER.info("Setting pod labels");
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should only be a debug level log as nothing exiting or too relevant happens here functionality wise.

Suggested change
LOGGER.info("Setting pod labels");
LOGGER.debug("Setting service labels");

@@ -444,6 +446,16 @@ protected void createAndApplyDeployment(String correlationId, String sessionReso
}
K8sUtil.loadAndCreateDeploymentWithOwnerReference(client.kubernetes(), client.namespace(), correlationId,
deploymentYaml, Session.API, Session.KIND, sessionResourceName, sessionResourceUID, 0, deployment -> {

LOGGER.info("Setting pod labels");
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should only be a debug level log as nothing exiting or too relevant happens here functionality wise.

Suggested change
LOGGER.info("Setting pod labels");
LOGGER.debug("Setting pod labels");

@jfaltermeier
Copy link
Contributor

jfaltermeier commented Oct 23, 2024

I tested the current state and the labels are getting added as expected 👍

At the moment, in the EagerStartSessionHandler, we’re only adjusting the service labels, and in the LazySessionHandler, labels are only being added to deployments.

In the long run, I think we should consider adding the same labels to all deployments, services, and configmaps that are created. For the LazySessionHandler, this would mean updating the following:

  • createAndApplyService
  • createAndApplyEmailConfigMap
  • createAndApplyProxyConfigMap
  • createAndApplyDeployment

We could pass label maps to these methods now, and they would forward them to:

  • loadAndCreateServiceWithOwnerReference
  • loadAndCreateConfigMapWithOwnerReference
  • loadAndCreateDeploymentWithOwnerReference

I think we may also ignore the EagerStartSessionHandler for now.
I am not sure if we should remove this handler for 1.0.0, since it does not cover all functionality anyway.

@lucas-koehler
Copy link
Contributor

In the long run, I think we should consider adding the same labels to all deployments, services, and configmaps that are created.

I agree: Eventually we should label all components created by Theia Cloud, either by the operator or the Helm charts.

I think we may also ignore the EagerStartSessionHandler for now.
I am not sure if we should remove this handler for 1.0.0, since it does not cover all functionality anyway.

I think we should leave it in but make very clear in the documentation on the website, the helm charts and potentially here that the implementation is not up to par. My reason for leaving it in is that it might encourage contributions to improve this and shows our intent on bringing this up to par eventually. Furthermore, it allows basic prototyping of eager start. WDYT?

@jfaltermeier
Copy link
Contributor

I think we should leave it in but make very clear in the documentation on the website, the helm charts and potentially here that the implementation is not up to par. My reason for leaving it in is that it might encourage contributions to improve this and shows our intent on bringing this up to par eventually. Furthermore, it allows basic prototyping of eager start. WDYT?

Sounds good

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