feat: Manage OpenVSX as Che operand

[svor]

What does this PR do?

• Deploy and manage a dedicated OpenVSX server and PostgreSQL database as Che operands,
  enabled via spec.components.openVSX.enable
• Expose OpenVSX via a dedicated Ingress (not the Che gateway), supporting both OpenShift
  and Kubernetes
• Auto-seed the database with a privileged user and admin PAT via a one-shot Job
• Support publishing extensions from a user-editable openvsx-extensions ConfigMap
• Persist extension storage on a PVC (default 3Gi, configurable via
  spec.components.openVSX.server.claimSize)
• Make openvsx-server-config ConfigMap user-editable with automatic pod rollout on
  changes

New CRD fields

• spec.components.openVSX.enable — enables the OpenVSX operand (default is false)
• spec.components.openVSX.server.claimSize — PVC size for extension storage (default:
  3Gi)
• spec.components.openVSX.server.deployment — deployment overrides
• spec.components.openVSX.database.claimSize — PVC size for PostgreSQL data (default:
  1Gi)
• spec.components.openVSX.database.deployment — deployment overrides
• status.openVSXURL — URL of the managed OpenVSX instance

Resources created when enabled

• openvsx-database: Deployment, Service, PVC, credentials Secret
• openvsx-server: Deployment, Service, PVC, ConfigMap (application config), ConfigMap
  (extensions list)
• openvsx-user-setup: one-shot Job to seed DB users and PATs
• openvsx-extension-publish: Job to publish extensions from the extensions ConfigMap
• openvsx: Ingress with platform-appropriate TLS and annotations

All resources are cleaned up when openVSX.enable is set to false.

Screenshot/screencast of this PR

What issues does this PR fix or reference?

https://issues.redhat.com/browse/CRW-10323

How to test this PR?

1. Deploy the operator:

OpenShift

./build/scripts/olm/test-catalog-from-sources.sh

or

build/scripts/docker-run.sh /bin/bash -c "
  oc login \
    --token=<...> \
    --server=<...> \
    --insecure-skip-tls-verify=true && \
  build/scripts/olm/test-catalog-from-sources.sh
"

on Minikube

./build/scripts/minikube-tests/test-operator-from-sources.sh

Common Test Scenarios

• Enable OpenVSX operand and verify all resources are created
• Publish extensions via openvsx-extensions ConfigMap

• Verify extensions survive pod restart (PVC persistence)
• Update openvsx-server-config ConfigMap and verify pod rollout

• Resize PVC via claimSize and verify expansion
• Disable OpenVSX operand and verify all resources are deleted
• Verify Ingress works on both OpenShift and Kubernetes

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• The repository devfile is up to date and works
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: svor

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[tolusha]

Hi! I'm che-ai-assistant — I help with your pull requests.

Available commands:

• /che-ai-assistant generate-che-doc — Generate a documentation PR based on this PR's changes
• /che-ai-assistant ok-pr-review — Run a comprehensive PR review (summary, code review, deep review, impact analysis)
• /che-ai-assistant help — Show this help message

[tolusha]

/che-ai-assistant ok-pr-review

Review is complete. Please check the review comments below.

[tolusha]

Code Review Findings

This is an automated review covering standard code quality, design patterns, operational readiness, and system-level concerns.

Critical Issues (Must Fix Before Merge)

1. Missing owner reference on Ingress

File: pkg/deploy/openvsx/openvsx-server/openvsx_server_ingress.go (around line 114)

The Ingress resource is created without setting controllerutil.SetControllerReference. This means it won't be garbage-collected when the CheCluster CR is deleted. Compare with openvsx_server_service.go and openvsx_database_service.go which both set owner references.

Add before the Sync call:

if err := controllerutil.SetControllerReference(ctx.CheCluster, ingress, ctx.ClusterAPI.Scheme); err != nil {
	return err
}

2. Missing owner reference on ConfigMap

File: pkg/deploy/openvsx/openvsx-server/openvsx_server_config.go:41

The openvsx-server ConfigMap lacks an owner reference, preventing automatic cleanup.

Add before CreateIfNotExists:

if err := controllerutil.SetControllerReference(ctx.CheCluster, cm, ctx.ClusterAPI.Scheme); err != nil {
	return err
}

3. Init containers not covered by security standards

File: pkg/deploy/deployment.go:EnsurePodSecurityStandards

The function only iterates podSpec.Containers, skipping podSpec.InitContainers. The DB provisioning Job uses an init container that won't receive the required SecurityContext. On restricted clusters (OpenShift SCC, Pod Security Admission), the init container will be rejected.

Extend the function to also iterate init containers:

for i := range podSpec.InitContainers {
	if podSpec.InitContainers[i].SecurityContext == nil {
		podSpec.InitContainers[i].SecurityContext = &corev1.SecurityContext{}
	}
	
	podSpec.InitContainers[i].SecurityContext.AllowPrivilegeEscalation = ptr.To(false)
	podSpec.InitContainers[i].SecurityContext.Capabilities = &corev1.Capabilities{Drop: []corev1.Capability{"ALL"}}
	podSpec.InitContainers[i].SecurityContext.RunAsNonRoot = ptr.To(true)
}

4. Missing Job deadline on database provisioning

File: pkg/deploy/openvsx/openvsx-database/openvsx_database_setup.go

The provisioning Job has no activeDeadlineSeconds. The init container loops indefinitely (sleep 5) waiting for migrations. If the server never starts, the Job runs forever.

Add to the Job spec:

ActiveDeadlineSeconds: ptr.To(int64(600)), // 10 minutes

5. Missing Job deadline on extension publisher

File: pkg/deploy/openvsx/openvsx-server/openvsx_server_extentions.go

Same issue - no maximum runtime for the extension-publish Job.

Add to the Job spec:

ActiveDeadlineSeconds: ptr.To(int64(600)), // 10 minutes

Warnings (Should Fix)

6. Typo in filename

File: pkg/deploy/openvsx/openvsx-server/openvsx_server_extentions.go

Filename should be openvsx_server_extensions.go (not "extentions").

7. Empty image string not guarded

File: pkg/common/operator-defaults/defaults.go

os.Getenv is used for OpenVSX images instead of ensureEnv. If the env vars are missing, empty image strings are returned, causing confusing errors later.

Consider adding validation in the reconciler:

image := defaults.GetOpenVSXImage(ctx.CheCluster)
if image == "" {
	return reconcile.Result{}, false, fmt.Errorf("RELATED_IMAGE_openvsx environment variable not set")
}

8. Typo in constant comment

File: pkg/common/constants/constants.go

Comment says OpenVSXRegsitry Common - should be OpenVSXRegistry Common.

Suggestions (Nice to Have)

9. Document in-memory state behavior (server)

File: pkg/deploy/openvsx/openvsx-server/openvsx_server.go

The extensionsVersion field resets to empty on operator restart. Add a comment explaining this is safe due to idempotency:

// extensionsVersion tracks the last synced ConfigMap version to avoid unnecessary Job churn.
// Resets on operator restart, which is safe - the Job is idempotent.
extensionsVersion string

10. Document in-memory state behavior (database)

File: pkg/deploy/openvsx/openvsx-database/openvsx_database.go

Same for databaseProvisioned:

// databaseProvisioned prevents recreating the setup Job on every reconcile.
// Resets on operator restart, which is safe - the Job uses ON CONFLICT DO NOTHING.
databaseProvisioned bool

11. Document destructive PVC deletion

File: pkg/deploy/openvsx/openvsx-database/openvsx_database.go:deleteResources

PVCs are deleted when enable=false, permanently destroying all data. This should be documented in the CRD field description or user docs. Consider adding a warning in the webhook when toggling from true to false.

12. Hostname prefix not configurable

File: pkg/common/constants/constants.go

The openvsx- prefix is hardcoded. Users cannot customize the hostname. Consider adding openVSXRegistry.server.hostname to the CRD for flexibility.

13. Add test for plugin registry interaction

File: api/v2/checluster_types_test.go (new test needed)

The new helper methods (IsInternalOpenVSXRegistryEnabled, IsExternalOpenVSXRegistryEnabled, IsInternalPluginRegistryWithOpenVSXEnabled) need a truth-table test covering all combinations of:

• openVSXRegistry.enable
• pluginRegistry.openVSXURL
• pluginRegistry.disableInternalRegistry

---

Positive Highlights

Excellent work on:

• Security: SQL uses parameterized variables, secrets handled correctly, pods have proper SecurityContext
• Architecture: Clean reconciler decomposition with proper dependency ordering (Secret → Database → Server)
• K8s patterns: ConfigMap ResourceVersion triggering rollouts is elegant and Kubernetes-native
• Idempotency: ON CONFLICT DO NOTHING in SQL, CreateIfNotExists for user-editable resources
• Test coverage: Good coverage of happy/sad paths for all reconcilers

The overall design is solid. The issues above are fixable polish items that will prevent operational problems.

---

Review generated by: ok-pr-review with Claude Sonnet 4.5

[openshift-ci]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.