Bug #113542 | delete sts,the operator not recreate the sts | ||
---|---|---|---|
Submitted: | 3 Jan 2024 9:35 | Modified: | 16 Jan 2024 18:00 |
Reporter: | Bing Ma (OCA) | Email Updates: | |
Status: | Won't fix | Impact on me: | |
Category: | MySQL Operator | Severity: | S2 (Serious) |
Version: | 8.2.0-2.1.1 | OS: | Any |
Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[3 Jan 2024 9:35]
Bing Ma
[15 Jan 2024 19:32]
MySQL Verification Team
Hi, Thank you for your report but I'm not sure I follow. What does happen when you delete a StatefulSet and what do you expect to happen?
[16 Jan 2024 1:29]
Bing Ma
nothing happened, expect to recreate the sts
[16 Jan 2024 1:30]
Bing Ma
the sts just deleted, I expect the sts to be recreated by the operator
[16 Jan 2024 18:00]
MySQL Verification Team
Hi, This is a behavior we do not plan to fix for now. If the user does something totally wrong; could be a slight mistake, might be a big chaos, might be purpose. Unless it's the slight mistake fixing this automatically however might lead to even more severe consequences. This is something we will revisit in future bot for now we will not change this behavior. Thank you for your interest in MySQL
[10 Apr 15:10]
Henno Schooljan
A Kubernetes operator must reconcile state to what is defined in the manifest, in this case the InnoDBCluster. This includes self-healing in case the state starts to differ from the definition. If the choice is made to not recover automatically, how does one recover in this case? The operator is aware the STS is not there as it is logging his warning: kopf.objects [WARNING ] STS doesn't exist yet. If this is a change during cluster start it might race and be lost What is the procedure to recreate the STS?