Remote cluster Liqo version detection

[thisiskazem]

Describe the problem you are having (if any)

Today, Liqo has no built-in mechanism to retrieve the Liqo version running on a remote cluster. At the moment, the only way to discover the Liqo version of a cluster is by running liqoctl version using a full-access kubeconfig of that cluster. This greatly limits automation and prevents operators from observing version compatibility across clusters.

Describe the solution you would like

To improve this, Liqo needs a native feature that allows retrieving and exposing the remote cluster’s Liqo version, in scenarios both with and without an established peering. The goal is to make version discovery automatic, secure, lightweight, and available directly from Liqo’s APIs and CRDs.

For scenarios where a peering exists, one possible approach is to introduce a simple ConfigMap stored on each cluster that contains the current Liqo version. After peering, the consumer cluster would automatically read this ConfigMap from the remote cluster using a dedicated Role and RoleBinding that grant read-only access to this single resource. The retrieved version can then be stored in the ForeignCluster CRD (e.g., in a status.remoteVersion field), allowing operators and controllers to easily inspect the version through standard Kubernetes APIs. This method is secure, minimal, and fully aligned with how Liqo already shares other objects across clusters.

For scenarios where no peering is established, Liqo could embed a small “agent” responsible for storing general cluster metadata—such as the Liqo version—and exposing it externally through a lightweight read-only endpoint. This agent would not require full Kubernetes API access and can run even before any peering is configured. Tools or controllers could contact this endpoint directly to retrieve the version and other metadata. This would allow Liqo to support use cases where operators need to validate remote cluster capabilities before peering or when clusters intentionally do not exchange identities.

Describe the user value of this feature

Adding such a unified version-discovery mechanism would give Liqo an essential building block for upgrade automation, compatibility checks, pre-peering validations, and improved multi-cluster observability. It also removes the current dependency on full kubeconfig files or manual operations, making Liqo more robust and easier to automate.

Describe your proposed solution

No response

Do you volunteer to implement this feature?

• I want to implement this feature

Code of Conduct

• I agree to follow this project's Code of Conduct