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

OLM sometimes creates two install plans for a subscription #13

Open
joelanford opened this issue Aug 7, 2020 · 1 comment
Open

OLM sometimes creates two install plans for a subscription #13

joelanford opened this issue Aug 7, 2020 · 1 comment
Labels
blocked-by-olm Related to an OLM feature or bug that blocks this issue/PR

Comments

@joelanford
Copy link
Member

I ran:

kubectl operator install etcd -w "default" -C

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.

@joelanford joelanford added the blocked-by-olm Related to an OLM feature or bug that blocks this issue/PR label Nov 24, 2020
@joelanford
Copy link
Member Author

joelanford commented Nov 2, 2021

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:

  1. Creates the subscription
  2. Waits for the subscription's status.installPlanRef to be set.
  3. Fetches the install plan found in 2)
  4. 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.

recharte added a commit to percona/everest that referenced this issue Jun 27, 2024
We introduced this phase check because OLM has a bug where it sometimes
creates duplicate InstallPlans for the same CSV and we found a few cases
where the duplicate InstallPlan wasn't reconciled correctly and
abandoned by OLM. This abandoned InstallPlan was missing the status
field meaning it was also missing the necessary plan to install the
operator. Approving this InstallPlan would cause the operator to never
be installed. By checking the phase we make sure we will be approving an
InstallPlan that is actually ready to be approved. See
operator-framework/kubectl-operator#13 for
more details on a similar issue.
oksana-grishchenko pushed a commit to percona/everest that referenced this issue Jun 27, 2024
* EVEREST-1182 fix install of everest operator

We introduced this phase check because OLM has a bug where it sometimes
creates duplicate InstallPlans for the same CSV and we found a few cases
where the duplicate InstallPlan wasn't reconciled correctly and
abandoned by OLM. This abandoned InstallPlan was missing the status
field meaning it was also missing the necessary plan to install the
operator. Approving this InstallPlan would cause the operator to never
be installed. By checking the phase we make sure we will be approving an
InstallPlan that is actually ready to be approved. See
operator-framework/kubectl-operator#13 for
more details on a similar issue.

* EVEREST-1182 fix idempotency of the install command
recharte added a commit to percona/everest that referenced this issue Jun 27, 2024
* EVEREST-1182 fix install of everest operator

We introduced this phase check because OLM has a bug where it sometimes
creates duplicate InstallPlans for the same CSV and we found a few cases
where the duplicate InstallPlan wasn't reconciled correctly and
abandoned by OLM. This abandoned InstallPlan was missing the status
field meaning it was also missing the necessary plan to install the
operator. Approving this InstallPlan would cause the operator to never
be installed. By checking the phase we make sure we will be approving an
InstallPlan that is actually ready to be approved. See
operator-framework/kubectl-operator#13 for
more details on a similar issue.

* EVEREST-1182 fix idempotency of the install command
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked-by-olm Related to an OLM feature or bug that blocks this issue/PR
Projects
None yet
Development

No branches or pull requests

1 participant