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

Register MySQL Operator into OperatorHub.io #244

Open
AMecea opened this issue Mar 4, 2019 · 2 comments
Open

Register MySQL Operator into OperatorHub.io #244

AMecea opened this issue Mar 4, 2019 · 2 comments

Comments

@AMecea
Copy link
Contributor

AMecea commented Mar 4, 2019

https://www.operatorhub.io/contribute

@AMecea AMecea modified the milestones: 0.2.6, 0.2.7 Mar 4, 2019
@AMecea AMecea modified the milestones: 0.2.7, 0.3.x Mar 21, 2019
@AMecea
Copy link
Contributor Author

AMecea commented Apr 2, 2019

@komish
Copy link

komish commented Jan 15, 2020

Hi @AMecea!

I understand that Orchestrator is a stateful component and is primarily the motivation behind making use of the statefulset as the operator deployment methology. Could you give some examples of which statefulset behaviors are key for Orchestrator? Is it possible to decouple the Operator from the Orchestrator and have them communicate through some other method or do they need to live in the same pod?

Not super familiar with Orchestrator here, but I am trying to get more information on the statefulset use case here and see if there's a way we can approach it that might resolve the dependency on operator-framework/operator-lifecycle-manager#767 in the meantime.

@calind calind removed this from the 0.3.x milestone Oct 11, 2021
chapsuk pushed a commit to chapsuk/mysql-operator that referenced this issue Oct 16, 2023
chapsuk pushed a commit to chapsuk/mysql-operator that referenced this issue Oct 16, 2023
* Set vttablet init container resource requests and limits

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 bitpoke#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 bitpoke#216 with the change that it no longer sets a default resource _limit_.

This fixes the issue reported in bitpoke#240 and discussed in bitpoke#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 bitpoke#212
fixes bitpoke#240

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

* refactor: move defaults to the correct location

Signed-off-by: Manan Gupta <manan@planetscale.com>

---------

Signed-off-by: J. Brandt Buckley <brandt@runlevel1.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Co-authored-by: J. Brandt Buckley <brandt@runlevel1.com>
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

No branches or pull requests

3 participants