Enable the managed Open VSX registry
|
The managed Open VSX registry is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/. |
Enable Che to deploy and manage a dedicated Open VSX server with a PostgreSQL database as Operator-managed components. The managed registry is exposed through the Che gateway and provides a private, curated extension registry without requiring manual deployment or database administration.
When enabled, the Che Operator creates the following resources:
-
An Open VSX server
Deploymentwith aPersistentVolumeClaimfor extension storage. -
A PostgreSQL database
Deploymentwith aPersistentVolumeClaimfor data. -
A one-shot
Jobto provision the database with the required user and access token. -
A
ConfigMapfor listing extensions to publish to the registry.
When disabled, the Operator removes all managed Open VSX resources.
-
An active
kubectlsession with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.
-
Enable the managed Open VSX registry by patching the
CheClustercustom resource:kubectl patch checluster eclipse-che \ --namespace eclipse-che \ --type merge \ --patch '{ "spec": { "components": { "openVSXRegistry": { "enable": true } } } }'The Operator deploys the Open VSX server and PostgreSQL database, provisions the database, and exposes the registry through the Che gateway.
The managed registry starts empty with no pre-installed extensions. You must publish extensions to the registry after enabling it. -
Optional: Configure the server storage size by setting the
claimSizefield. The default is3Gi.kubectl patch checluster eclipse-che \ --namespace eclipse-che \ --type merge \ --patch '{ "spec": { "components": { "openVSXRegistry": { "server": { "pvc": { "claimSize": "<size>" } } } } } }'where
<size>is the required storage size. For example:5Gi. -
Optional: Configure the database storage size. The default is
1Gi.kubectl patch checluster eclipse-che \ --namespace eclipse-che \ --type merge \ --patch '{ "spec": { "components": { "openVSXRegistry": { "database": { "pvc": { "claimSize": "<size>" } } } } } }' -
Optional: Publish extensions to the managed registry by editing the
openvsx-server-extensionsConfigMapin the Che namespace. Add extension.vsixdownload URLs, one per line:kubectl edit configmap openvsx-server-extensions \ --namespace eclipse-cheThe Operator automatically runs a publishing
Jobwhen theConfigMapcontent changes.
-
Verify that the Open VSX server and database pods are running:
kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-database -
Access the Open VSX registry UI by navigating to
https://<che_host>/openvsxin a browser, where<che_host>is the hostname of your Che instance. You can retrieve the URL from theCheClusterstatus:kubectl get checluster eclipse-che \ --namespace eclipse-che \ -o jsonpath='{.status.openVSXURL}' -
Open a workspace and verify that extensions from the managed registry are available in the Extensions view.
Configure custom credentials for the managed Open VSX registry
By default, the Operator generates an openvsx-credentials secret with random passwords and access tokens. To use custom database credentials and Open VSX user accounts, create a secret and reference it in the CheCluster custom resource.
|
The secret must exist before it is referenced in the |
-
An active
kubectlsession with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.
-
Create a secret with the required credentials:
kubectl create secret generic <secret_name> \ --namespace eclipse-che \ --from-literal=database-user=<db_user> \ --from-literal=database-password=<db_password> \ --from-literal=database-name=<db_name> \ --from-literal=openvsx-publisher-name=<publisher_name> \ --from-literal=openvsx-publisher-token=<publisher_token> \ --from-literal=openvsx-admin-name=<admin_name> \ --from-literal=openvsx-admin-token=<admin_token>kubectl label secret <secret_name> \ --namespace eclipse-che \ app.kubernetes.io/part-of=che.eclipse.orgThe secret must contain all of the following keys:
Key Description database-userPostgreSQL username.
database-passwordPostgreSQL password.
database-namePostgreSQL database name.
openvsx-publisher-nameLogin name of the Open VSX publisher account with the
privilegedrole.openvsx-publisher-tokenPersonal access token for the publisher account.
openvsx-admin-nameLogin name of the Open VSX admin account.
openvsx-admin-tokenPersonal access token for the admin account.
-
Reference the secret in the
CheClustercustom resource:kubectl patch checluster eclipse-che \ --namespace eclipse-che \ --type merge \ --patch '{ "spec": { "components": { "openVSXRegistry": { "enable": true, "credentialsSecretName": "<secret_name>" } } } }'
-
Verify that the Open VSX server pod is running:
kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server -
Verify that the custom credentials are injected as environment variables in the Open VSX server pod:
kubectl exec deploy/openvsx-server \ --namespace eclipse-che -- \ env | grep -E 'OPENVSX_ADMIN_PAT|OPENVSX_USER_PAT'The output should include
OPENVSX_ADMIN_PATandOPENVSX_USER_PAT. -
Verify that the database pod uses the custom credentials:
kubectl exec deploy/openvsx-database \ --namespace eclipse-che -- \ env | grep -E 'POSTGRESQL_'
Customize the Open VSX server configuration
The Operator creates an openvsx-server ConfigMap with a default application.yml configuration when the managed registry is first enabled. This ConfigMap is user-editable: the Operator creates it once and does not overwrite subsequent changes. Modifying the ConfigMap automatically triggers a rolling restart of the Open VSX server pod.
-
An active
kubectlsession with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl. -
The managed Open VSX registry is enabled and running.
-
Edit the
openvsx-serverConfigMap:kubectl edit configmap openvsx-server \ --namespace eclipse-cheThe
ConfigMapcontains a singleapplication.ymlkey with the Open VSX Spring Boot configuration.
-
Verify that the Open VSX server pod has restarted with the updated configuration:
kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server
Delete extensions from the managed Open VSX registry
Delete individual extensions or specific extension versions from the managed Open VSX registry by using the Open VSX admin API.
-
An active
kubectlsession with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl. -
The managed Open VSX registry is enabled and running.
-
Get the Open VSX server pod name:
kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server -o name -
Delete an entire extension with all its versions:
kubectl exec <openvsx_server_pod> \ --namespace eclipse-che -- \ sh -c 'curl -X POST "http://openvsx-server:8080/openvsx/admin/api/extension/<extension_namespace>/<extension_name>/delete?token=$OPENVSX_ADMIN_PAT"'where:
<openvsx_server_pod>-
The pod name from the previous step.
<extension_namespace>-
The namespace (publisher) of the extension. For example:
redhat. <extension_name>-
The name of the extension. For example:
java.
-
Alternatively, to delete only a specific version of an extension:
kubectl exec <openvsx_server_pod> \ --namespace eclipse-che -- \ sh -c 'curl -X POST -H "Content-Type: application/json" \ -d '"'"'[{"version": "<extension_version>"}]'"'"' \ "http://openvsx-server:8080/openvsx/admin/api/extension/<extension_namespace>/<extension_name>/delete?token=$OPENVSX_ADMIN_PAT"'where
<extension_version>is the version to delete. For example:1.2.3.
-
Open the Open VSX registry UI and verify that the deleted extension is no longer listed.
Disable the managed Open VSX registry
Disable the managed Open VSX registry to remove the Open VSX server, PostgreSQL database, and all associated resources from the namespace.
-
An active
kubectlsession with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.
-
Set the
enablefield tofalse:kubectl patch checluster eclipse-che \ --namespace eclipse-che \ --type merge \ --patch '{ "spec": { "components": { "openVSXRegistry": { "enable": false } } } }'The Operator removes all managed Open VSX resources, including deployments, services, persistent volume claims, and secrets.
-
Verify that no Open VSX pods remain in the namespace:
kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-database