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

Ability to add tolerations to PEMs #598

Closed
aimichelle opened this issue Sep 22, 2022 · 3 comments
Closed

Ability to add tolerations to PEMs #598

aimichelle opened this issue Sep 22, 2022 · 3 comments
Labels
area/deployment Issues replated to deployments kind/feature New feature or request priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@aimichelle
Copy link
Member

Is your feature request related to a problem? Please describe.
Users would like to easily add tolerations in order to deploy PEMs to nodes that have taints.
This can be done by manually updating the resources to include the tolerations, however these changes aren't sticky after auto-updates.
You can currently use patches to add the toleration or nodeSelector to various resources, but this is prone to syntax errors. For example, setting a nodeSelector to the PEMs using helm:

patches.vizier-pem='\\{\"spec\"\: {\"template\"\: {\"spec\"\: { \"nodeSelector\"\: {\"pixie\"\: \"allow\" }}}}}' \

Describe the solution you'd like
Users should be able to easily specify tolerations for their PEMs through the CLI and Helm Chart. This should look similarly to how tolerations are specified on K8s resources.

@aimichelle aimichelle added kind/feature New feature or request area/deployment Issues replated to deployments priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Sep 22, 2022
@yousaf-aftab
Copy link

Hi @aimichelle I'm newbie and I'm interested in this issue. Can you tell a little bit about how you are passing toleration parameters in the following command

patches.vizier-pem='\\{\"spec\"\: {\"template\"\: {\"spec\"\: { \"nodeSelector\"\: {\"pixie\"\: \"allow\" }}}}}' \

because setting nodeSelector will not tolerate the taint, it will only match the labels of node and scheduler will try to schedule the pod on that node if the labels matches but it will not be scheduled if
you don't pass the tolerations as well.

@aimichelle
Copy link
Member Author

Hey @yousaf-aftab ! The patching mechanism is essentially performing the equivalent of a kubectl patch.

I think something similar to what was done for nodeSelector (example changes here #362) would work really well for the tolerations! Let me know if you have any questions after going through that PR.

aimichelle pushed a commit that referenced this issue Aug 4, 2023
Summary: Adds support for tolerations to enable users to deploy PEMs to
nodes that have taints through helm.

Relevant Issues: #598

Type of change: /kind feature

Test Plan: ran `helm install` using the [previous operator helm chart
](https://github.com/pixie-io/pixie/releases/download/release%2Foperator%2Fv0.1.4/pixie-operator-chart-0.1.4.tgz)
with these changes and verified that tolerations appear in the CRD.

Signed-off-by: Benjamin Kilimnik <bkilimnik@pixielabs.ai>
aimichelle pushed a commit that referenced this issue Aug 4, 2023
Summary: Adds support for tolerations to enable users to deploy PEMs to
nodes that have taints through the CLI.

Relevant Issues: #598

Type of change: /kind feature

Test Plan: Used skaffold to deploy an unreleased version of the
operator. Verified that tolerations parameter actually gets passed
through to the pod spec.

Signed-off-by: Benjamin Kilimnik <bkilimnik@pixielabs.ai>
@aimichelle
Copy link
Member Author

Closed thanks to @benkilimnik 's work on #1649 and #1648!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/deployment Issues replated to deployments kind/feature New feature or request priority/backlog Higher priority than priority/awaiting-more-evidence. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

2 participants