This repository has been archived by the owner on Oct 22, 2024. It is now read-only.
operator: Bump operator-sdk version to v1.13.1 #1051
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 6822551. Needed commits are merged to upstream.
Does it require packages from 1.22 or does the resulting PMEM-CSI only work with 1.22?
Supporting 1.22 does not mean that we compile against it. To minimize changes, in #1049 I am only changing deployment and testing, but not any compilation steps. |
It requires 1.22 packages and controller-runtime 0.7.0. But I don't think it restricts the operator to work only 1.22. |
|
Does using operator-sdk v1.13.1 have any specific advantages? It still doesn't seem to work with the latest OLM. |
I am still debugging it... |
Somehow latest release(v0.19.1) fails to start the operator, it stuck
while creating the install-plan for the subscription. The logs from
the catalog-source pod shows:
```
time="2021-11-15T13:51:07Z" level=info msg=syncing event=update reconciling="*v1alpha1.Subscription" selflink=
time="2021-11-15T13:51:07Z" level=info msg="syncing catalog source for annotation templates" catSrcName=pmem-csi-operator-catalog catSrcNamespace=default id=da6p4
time="2021-11-15T13:51:08Z" level=warning msg="an error was encountered during reconciliation" error="Operation cannot be fulfilled on subscriptions.operators.coreos.com \"pmem-csi-operator-v100-0-0-sub\": the object has been modified; please apply your changes to the latest version and try again" event=update reconciling="*v1alpha1.Subscription" selflink=
E1115 13:51:08.483478 1 queueinformer_operator.go:290] sync {"update" "default/pmem-csi-operator-v100-0-0-sub"} failed: Operation cannot be fulfilled on subscriptions.operators.coreos.com "pmem-csi-operator-v100-0-0-sub": the object has been modified; please apply your changes to the latest version and try again
```
avalluri
force-pushed
the
operator-sdk
branch
from
42f9185 to
a63b2be
Compare
|
OLM Installation failure is a bit strange: I guess some timing issue. Even though the OperatorGroup CRD was installed in the previous step, it fails to create an object of that kind. |
|
That failure to install OLM is different from the failure seen in the CI. In the CI, OLM installed okay but the PMEM-CSI operator didn't. |
|
See #1050 |
pohly
reviewed
Nov 17, 2021
| @@ -1,15 +1,9 @@ | |||
| OPERATOR_SDK_VERSION=1.6.1 | |||
| OPERATOR_SDK_VERSION=1.14.0 | |||
|
|
|||
| # download operator-sdk binary | |||
| _work/bin/operator-sdk-$(OPERATOR_SDK_VERSION): | |||
| mkdir -p _work/bin/ 2> /dev/null | |||
There was a problem hiding this comment.
Why the output redirection to /dev/null?
If there is an error, we want to see it.
pohly
reviewed
Nov 17, 2021
| git clone --branch $(OPERATOR_SDK_VERSION)+fixes https://github.com/avalluri/operator-sdk.git $$tmpdir && \ | ||
| cd $$tmpdir && $(MAKE) build/operator-sdk && \ | ||
| cp $$tmpdir/build/operator-sdk $(abspath $@) && \ | ||
| curl -L https://github.com/operator-framework/operator-sdk/releases/download/v$(OPERATOR_SDK_VERSION)/operator-sdk_linux_amd64 -o $(abspath $@) | ||
| chmod a+x $(abspath $@) | ||
| cd $(dir $@); ln -sf operator-sdk-$(OPERATOR_SDK_VERSION) operator-sdk |
There was a problem hiding this comment.
These rules are unnecessarily complex. This is simpler:
_work/bin/operator-sdk-$(OPERATOR_SDK_VERSION):
mkdir -p _work/bin
curl -L https://github.com/operator-framework/operator-sdk/releases/download/v$(OPERATOR_SDK_VERSION)/operator-sdk_linux_amd64 -o $@
chmod a+x $@
ln -sf operator-sdk-$(OPERATOR_SDK_VERSION) $(@D)/operator-sdk
|
The new operator-sdk is unhappy about our bundle. I checked out your branch and ran: Why is |
|
Ah, |
|
Here's a similar PR that works for me, please review: #1052 |
|
Now. the new build (operator-sdk v1.14.0 and OLM v0.18.3) succeeds without any fialures. But. anyways as #1052 addresses the same issue I am closing in favor of that. |
|
I'm confused. Why are you not getting the "invalid service account found in bundle. sa name cannot match service account defined for deployment spec in CSV"? Is it because you switched to operator-sdk 1.14.0? We should have an explanation for this instead of finding a working combination via trial-and-error. |
That was a false herring, right? It doesn't matter at all which Kubernetes dependencies the operator-sdk has. What matters is its output. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The most recent operator-sdk version is 1.14.0 which requires k8s 1.22. We can upgrade to 1.14 as part of adding 1.22 support to the driver.