You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems to result in a successful installation, but there's an extra install plan in the namespace for etcd, which remains un-approved.
According to OLM maintainers, the duplicate install plan issue is a bug. OLM will auto delete all but the latest 5 install plans, so we could delete the duplicate install plan in kubectl operator code, but it doesn't seem strictly necessary.
The text was updated successfully, but these errors were encountered:
Update: I just attempted to reproduce this issue, and I noticed that kubectl operator approved the "wrong" install plan. Looking at the kubectl operator code, it appears as if it:
Creates the subscription
Waits for the subscription's status.installPlanRef to be set.
Fetches the install plan found in 2)
Updates the install plan found in 2) by setting spec.approved to true.
Therefore, OLM is setting an install plan reference on the subscription and then (sometimes) immediately re-reconciling the subscription, creating another install plan, and then updating the install plan reference, rendering the first approved install plan inert. When kubectl operator is fast enough (or OLM is slow enough), kubectl operator is able to pick up the first install plan just before it becomes inert, eventually causing the install to timeout and fail.
I ran:
This seems to result in a successful installation, but there's an extra install plan in the namespace for etcd, which remains un-approved.
According to OLM maintainers, the duplicate install plan issue is a bug. OLM will auto delete all but the latest 5 install plans, so we could delete the duplicate install plan in
kubectl operator
code, but it doesn't seem strictly necessary.The text was updated successfully, but these errors were encountered: