feat/upgrade-deps

[roivaz]

This PR upgrades libs and operator-sdk to latest possible ones, within constrains. Operator SDK manifest generation has been refactored for better maintenance, making it clear where the manifests have been customized within the Kustomize resources. Most of the operator-sdk project scaffolding has been regenerated using the latest version.

Operator SDK has been bumped just to 1.10 as there is an ongoing issue for higher versions, still unresolved even though the issue that was reported is already closed: operator-framework/operator-sdk#5244

/kind feature
/priority important-soon
/assign

[roivaz]

/ok-to-test

[slopezz]

/lgtm

[3scale-robot]

LGTM label has been added.

Git tree hash: f8e9cea2520ddae629bc64cea88effa8d211c37b

[raelga]

/lgtm

[roivaz]

@raelga @slopezz while installing in staging I detected a couple of problems, which I have fixed in the follwing commits:

• cd21723 - Fix catalog build and publication targets
• 6c62f0a - Fix WATCH_NAMESPACE envvar for OLM installation
• ba9946c - Fix version number

Could you please review these extra commits and approve?

[slopezz]

Can you please elaborate a bit more regarding cd21723 - Fix catalog build and publication targets @roivaz

I tried to understand the new complexity, but would appreciate an explanation with the motivation of the change

Until now we had:

BUNDLE_IMG ?= quay.io/3scale/marin3r-bundle:v$(VERSION)
INDEX_IMG ?= quay.io/3scale/marin3r-catalog:latest

index-build: $(OPM)
	$(OPM) index add \
		--build-tool docker \
		--mode semver \
		--bundles $(BUNDLE_IMG) \
		--from-index $(INDEX_IMG) \
		--tag $(INDEX_IMG)

index-push:
	docker push $(INDEX_IMG)

And now:

IMAGE_TAG_BASE ?= quay.io/3scale/marin3r

# BUNDLE_IMG defines the image:tag used for the bundle.
# You can use it as an arg. (E.g make bundle-build BUNDLE_IMG=<some-registry>/<project-name-bundle>:<tag>)
BUNDLE_IMG ?= $(IMAGE_TAG_BASE)-bundle:v$(VERSION)

# A comma-separated list of bundle images (e.g. make catalog-build BUNDLE_IMGS=example.com/operator-bundle:v0.1.0,example.com/operator-bundle:v0.2.0).
# These images MUST exist in a registry and be pull-able.
BUNDLE_IMGS ?= $(BUNDLE_IMG)

# The image tag given to the resulting catalog image (e.g. make catalog-build CATALOG_IMG=example.com/operator-catalog:v0.2.0).
CATALOG_IMG ?= $(IMAGE_TAG_BASE)-catalog:v$(VERSION)

# Default catalog base image to append bundles to
CATALOG_BASE_IMG ?= $(IMAGE_TAG_BASE)-catalog:latest

# Set CATALOG_BASE_IMG to an existing catalog image tag to add $BUNDLE_IMGS to that image.
ifneq ($(origin CATALOG_BASE_IMG), undefined)
FROM_INDEX_OPT := --from-index $(CATALOG_BASE_IMG)
endif

.PHONY: catalog-build
catalog-build: opm ## Build a catalog image.
	$(OPM) index add --container-tool docker --mode semver --tag $(CATALOG_IMG) --bundles $(BUNDLE_IMGS) $(FROM_INDEX_OPT)

# Push the catalog image.
.PHONY: catalog-push
catalog-push: ## Push a catalog image.
	$(MAKE) docker-push IMG=$(CATALOG_IMG)

catalog-retag-latest:
	docker tag $(CATALOG_IMG) $(IMAGE_TAG_BASE)-catalog:latest
	$(MAKE) docker-push IMG=$(IMAGE_TAG_BASE)-catalog:latest

[roivaz]

The new targets are what operator-sdk creates now by default when scaffolding a new project. Up until now, the Makefile didn't came with targets to manage the catalog, so that's why we had our own ones. Also, the catalog is now versioned, which enables for easy rollbacks. I just had to add the catalog-retag-latest target to keep using the latest tag as before.

[slopezz]

The new targets are what operator-sdk creates now by default when scaffolding a new project. Up until now, the Makefile didn't came with targets to manage the catalog, so that's why we had our own ones. Also, the catalog is now versioned, which enables for easy rollbacks. I just had to add the catalog-retag-latest target to keep using the latest tag as before.

Thanks for the explanation, fair enough!

/lgtm

[3scale-robot]

LGTM label has been added.

Git tree hash: 43cc3ad5f5137ebcacd4073481ea5cbcedeaae5b

[raelga]

/lgtm

[roivaz]

/approve

[3scale-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: roivaz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [roivaz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment