Skip to content

feat(olm): publish-ready metadata for OperatorHub (1.3.5) - #114

Merged
enriqueavindi merged 5 commits into
mainfrom
feat/operatorhub-metadata
Nov 5, 2026
Merged

enriqueavindi merged 5 commits into
mainfrom
feat/operatorhub-metadata

Conversation

@enriqueavindi

Copy link
Copy Markdown
Contributor

What and why

The bundle metadata was still the operator-sdk scaffold, so the operator is not submittable to OperatorHub: placeholder link, scaffold maintainer name, no category, a one-line description and alm-examples with spec: null. This PR fixes the metadata and prepares the 1.3.5 release that will be submitted.

Nothing changes at runtime: no Go code, no RBAC, no CRDs, no webhooks.

Changes

File Change
config/manifests/bases/...clusterserviceversion.yaml displayName, 3-section description, links, maintainers, provider, category, annotations
config/manifests/patches/icon.yaml icon re-cut to a square
config/samples/overcommit_v1_overcommit*.yaml valid specs (they had the # TODO stub)
bundle/metadata/dependencies.yaml new — cert-manager dependency
Makefile, chart/Chart.yaml, chart/values.yaml, deploy/catalog_source.yaml 1.3.4 → 1.3.5
bundle/, deploy/olm/1.3.5/, deploy/chart/1.3.5/ regenerated with make bundle

Details:

  • Description now has the three sections the hub's PR template requires, in order: what the operator manages, features, prerequisites.
  • Links point to the docs tree pinned at the 1.3.5 tag, the repository and the blog post. A bundle is immutable, so the docs link must not follow main.
  • maintainers: Enrique Andrés Villar with the team alias as contact; provider: InditexTech + URL, the same shape redkey-operator uses.
  • alm-examples: the samples were the scaffold stub, which produced "spec": null objects that the console rendered as empty examples. They now carry a valid OvercommitLabel and a valid OvercommitClass (the CRD requires cpuOvercommit, memoryOvercommit and excludedNamespaces).
  • icon: was 750x1000, i.e. portrait in a slot the hub draws square. Re-cut to 700x700 by changing the viewBox around the artwork bounding box; no rasterisation, same vector paths, verified that nothing is clipped.

cert-manager: declared as a bundle dependency

cert-manager is mandatory — without it the per-class Certificate/Issuer never become ready and the generated mutating webhooks have no serving certificate.

Two things were wrong before:

  1. The CSV declared it in customresourcedefinitions.required, which makes OLM block the install until those CRDs exist, but nothing pulls cert-manager in. On a clean cluster the CSV stays Pending forever, and the hub's installation test (kind + subscription) never sees a pod.
  2. There was no bundle/metadata/dependencies.yaml, so OLM had no way to resolve it.

This PR adds the dependency as olm.gvk:

dependencies:
- type: olm.gvk
  value: {group: cert-manager.io, kind: Certificate, version: v1}
- type: olm.gvk
  value: {group: cert-manager.io, kind: Issuer, version: v1}

olm.gvk rather than olm.package on purpose: any provider of the API satisfies it. With olm.package: cert-manager, a cluster that already runs cert-manager from Helm or plain manifests would get a second cert-manager installed by OLM, and the two controllers would fight over the same webhooks. With olm.gvk, OLM installs cert-manager from the catalog only when nothing provides the API.

The required block is removed because the dependency expresses the same thing and does not deadlock the install; the prerequisite is documented in the CSV description.

Version bump

release.yml compares tag_name against VERSION, chart.appVersion, chart.values.tag and the catalog image tag, so all four move to 1.3.5 together, plus config/manager/kustomization.yaml and the containerImage annotation. 1.3.5 (not 1.3.4) because the bundle image for 1.3.4 is already published and re-pointing that tag breaks immutability.

Verification

make bundle                                        # no diff afterwards, bundle validate passes
operator-sdk bundle validate ./bundle --select-optional suite=operatorframework
operator-sdk bundle validate ./bundle --select-optional name=operatorhub

Bundle CSV checked by hand: version: 1.3.5, displayName: K8s Overcommit Operator, deployment image ghcr.io/inditextech/k8s-overcommit-operator:1.3.5, no replaces/skipRange (first version of the package), alm-examples free of null specs, icon image/svg+xml 700x700.

Next

Once this is merged: tag 1.3.5 + release to publish the operator, bundle and catalog images, then the submission PR to k8s-operatorhub/community-operators with the bundle contents.

The CSV was still the operator-sdk scaffold: placeholder link, scaffold
maintainer, no category, no long description, and alm-examples with
`spec: null` because the samples carried the TODO stub.

- displayName, three-section description (what it does / features /
  prerequisites) and the short annotation the hub shows in listings.
- links: docs pinned to the release tag, source code, blog post. The
  scaffold URL https://k8s-overcommit.domain is gone.
- maintainers: real name, team alias as contact. provider: InditexTech
  with its URL, same shape as redkey-operator.
- categories: OpenShift Optional; containerImage, repository, support
  and extra keywords added.
- samples get valid specs, so alm-examples renders usable objects.
- icon re-cut to a 700x700 square (it was 750x1000, the hub shows it in
  a square slot). Same artwork, only the viewBox changes.
- cert-manager declared in bundle/metadata/dependencies.yaml as two
  olm.gvk entries (Certificate, Issuer). Not olm.package on purpose: any
  provider satisfies it, so clusters already running cert-manager
  outside OLM do not get a second one installed on top.

Signed-off-by: Enrique Andrés Villar <enriqueavi@inditex.com>
Bump VERSION, chart appVersion, chart image tag and catalog source to
1.3.5 and regenerate the bundle, so the release workflow's four-way
version check stays consistent. The bundle now carries the metadata from
the previous commit plus the x/net bump from #113.

Signed-off-by: Enrique Andrés Villar <enriqueavi@inditex.com>
@enriqueavindi
enriqueavindi requested a review from a team as a code owner November 4, 2026 15:32
SonarCloud flags the `Consistency` rule on `{{...}}` and `{{ ...}}` in the
chart templates. Whitespace inside a template directive is ignored by the
Go template parser, so the rendered output is byte-identical: verified with
`helm template` before and after the change.

The generated copy under `deploy/chart/1.3.5/` is regenerated with
`make bundle`.

Signed-off-by: Enrique Andrés Villar <enriqueavi@inditex.com>
Replaces the placeholder with the infrastructure team address that will
receive OperatorHub notifications.

Signed-off-by: Enrique Andrés Villar <enriqueavi@inditex.com>
OCP 4.x ships Kubernetes 1.(x+13), so OCP 4.15 is the first release with
Kubernetes 1.28, where `matchConditions` is enabled by default in the
admissionregistration API. The generated MutatingWebhookConfiguration uses
that field to honour `spec.excludedNamespaces`; on an older API server the
field is pruned and the webhook would apply to every namespace, including
kube-system and openshift-*.

`minKubeVersion` is raised to 1.28.0 for the same reason: it is the claim
OLM enforces before installing on a plain Kubernetes cluster.

`operator-sdk generate bundle` does not carry the annotation from the CSV
into `metadata/annotations.yaml` nor into `bundle.Dockerfile`, so `make
bundle` injects it (idempotently) after generation.

Signed-off-by: Enrique Andrés Villar <enriqueavi@inditex.com>
@sonarqubecloud

sonarqubecloud Bot commented Nov 5, 2026

Copy link
Copy Markdown

@luisreciomelero luisreciomelero left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@enriqueavindi
enriqueavindi merged commit cac38a8 into main Nov 5, 2026
24 checks passed
@enriqueavindi
enriqueavindi deleted the feat/operatorhub-metadata branch November 5, 2026 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants