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

Set vttablet init container resource requests and limits #256

Conversation

brandt
Copy link
Contributor

@brandt brandt commented Mar 6, 2022

Sets the resource requirements on each of the default vttablet init containers to the same request and limit values as the vttablet container itself.

This fixes the issue reported in #212 where pods would fail to be created on clusters with strict quota requirements because no limit was set on the init containers.

History

This is a reimplementation of #216 with the change that it no longer sets a default resource limit.

This fixes the issue reported in #240 and discussed in #244 where the vttablet pod would fail to be created when the user sets a request larger than the default limit without also setting a larger limit. The user's nil limit would not override the default value because update.ResourceRequirements(dst, src) won't update dst with a nil src (for good reasons).

With this change, users can once again increase the request by itself. If a cluster requires a limit, the user will already need to have set it on for vttablet so we can use the same value to override the init containers' default nil limit.

fixes #212
fixes #240

Signed-off-by: J. Brandt Buckley brandt@runlevel1.com

Sets the resource requirements on each of the default vttablet init containers to the same request and limit values as the vttablet container itself.

This fixes the issue reported in planetscale#212 where pods would fail to be created on clusters with strict quota requirements because no limit was set on the init containers.

## History

This is a reimplementation of planetscale#216 with the change that it no longer sets a default resource _limit_.

This fixes the issue reported in planetscale#240 and discussed in planetscale#244 where the vttablet pod would fail to be created when the user sets a request larger than the default limit without also setting a larger limit. The user's nil limit would not override the default value because `update.ResourceRequirements(dst, src)` won't update `dst` with a nil `src` ([for good reasons](https://github.com/planetscale/vitess-operator/blob/da7efd4c945193864f5996cb793055449c4de97a/pkg/operator/update/podspec.go#L201-L203)).

With this change, users can once again increase the request by itself. If a cluster requires a limit, the user will already need to have set it on for vttablet so we can use the same value to override the init containers' default nil limit.

fixes planetscale#212
fixes planetscale#240

Signed-off-by: J. Brandt Buckley <brandt@runlevel1.com>
@mattlord
Copy link
Collaborator

mattlord commented Mar 9, 2022

@brandt There are others better suited for the review, but I just wanted to say THANK YOU for the contribution! It's really nice to see non-PlanetScale contributors to the operator. ❤️

@brandt
Copy link
Contributor Author

brandt commented Mar 9, 2022

@mattlord My pleasure!

@deepthi deepthi requested a review from Verolop June 9, 2022 19:28
@GuptaManan100 GuptaManan100 added this to Review in Release 2.9.0 Jul 13, 2022
Copy link
Collaborator

@GuptaManan100 GuptaManan100 left a comment

Choose a reason for hiding this comment

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

Other than this, everything else looks good to me. Merging main might be required for running the workflows which are marked required but didn't exist when the PR was created

Comment on lines +52 to +53
defaultInitCPURequestMillis = 100
defaultInitMemoryRequestBytes = 32 * (1 << 20) // 32 MiB
Copy link
Collaborator

Choose a reason for hiding this comment

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

@GuptaManan100
Copy link
Collaborator

@brandt Are you still working on this? We would like to get this change in before we do the next release.

@GuptaManan100
Copy link
Collaborator

Closed in favour of #370

Release 2.9.0 automation moved this from Review to Done Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

initContainer defaults preventing existing YAML from working Ability to define resources for init containers
3 participants