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

Support global vars, volumes and volumeMounts for workspace statefulsets within helm chart #749

Open
drduker opened this issue Nov 14, 2024 · 2 comments
Labels
impact/usability Something that impacts users' ability to use the product easily and intuitively kind/enhancement Improvements or new features

Comments

@drduker
Copy link

drduker commented Nov 14, 2024

Hello!

Support global vars, volumes and volumeMounts for workspace statefulsets from the operator being supported in the helm chart templates.

This is really an ask that should require two changes:

  1. Add helm templating to create a place for global values or a flag to have workspace pods inherit envs,volumes and volumeMounts from the operator config.
  2. Make the operator deploy statefulsets using additional global configs in addition to what comes from the workspaceTemplate with the stack configs.
  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Affected area/feature

@drduker drduker added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Nov 14, 2024
@EronWright
Copy link
Contributor

EronWright commented Nov 19, 2024

I take this as a feature request to provide for global customization of the Workspace. I suppose the operator could have a cluster-scoped and/or namespace-scoped configuration object, providing a default workspace template (and would be merged with the stack's own template). The Helm chart could then produce this object.

A possible workaround would be to use a mutating webhook, to apply some defaults into the Stack object or directly into the Workspace object.

@drduker to help make the case for this feature, could you share some specific use cases that you have in mind?

@EronWright EronWright added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Nov 19, 2024
@drduker
Copy link
Author

drduker commented Nov 19, 2024

Use case is an offline deployment where you have local libraries that require netrc variables set. This vars need to go onto the workspace pods. Could use kyvero yes. I’m setting the values per stack in the workspace template values now. But it’s redundant and was not quick to find the usage for that. Had to look up spec and play around with that.

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Nov 19, 2024
@blampe blampe added impact/usability Something that impacts users' ability to use the product easily and intuitively and removed needs-triage Needs attention from the triage team labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/usability Something that impacts users' ability to use the product easily and intuitively kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

4 participants