Addon dependencies version range

[merusso]

As a KubeVela addon developer, when defining dependencies for an addon in metadata.yaml, I would like to set a version range for these dependencies, so that my addon will be restricted from being enabled in a cluster where the dependency version doesn't match the specified range.

I see in the docs that there is a dependencies[].version property, but KubeVela doesn't seem to use this value to enforce any version requirements. Ideally this property would work similarly to the existing system property.

For example, in "metadata.yaml":

name: my-addon
version: 0.1.0

dependencies:
  - name: fluxcd
    version: ">= 2.3.3, < 3.0.0"
  - name: foo
    version: ">= 0.1.0, < 1.0.0"

system:
  vela: ">= v1.7.0"
  kubernetes: ">= 1.24.0"

Specific behavior:

• When enabling addon, check whether dependencies are enabled within existing cluster.
• For any dependency that is already enabled, verify that version matches provided version range.
  • If version is outside range, fail. Do not update dependency version.
• For any dependency that is not enabled, attempt to enable while considering version range.
  • Fetch all versions of the addon, and enable the latest version that matches the version range.
  • If no addon version is available that matches the version range, fail.

[merusso]

As discussed in our most recent community meeting, this would introduce a breaking change, since existing usages of dependencies.version do not currently enforce any constraint.

We can avoid this issue by using a new property, but this leads to other questions:

• What's a good name for this new property?
• Should this new property deprecate (and eventually replace) the old property?
• Are these properties mutually exclusive? If not, what's the behavior when both are used?

Alternatively, we could add a feature flag to enable the version constraint behavior. Only if enabled, KubeVela checks whether the enabled version matches the version constraint and fails if the addon doesn't meet the constraint. The flag would be disabled by default to preserve backward compatibility.

[wonderflow]

Hi @merusso

I walked through all our addons in the catalog, almost all of the addons use dependency without specifying the version, like:

dependencies:
  - name: fluxcd

In this case, we can keep the compatiblity for this schematic: 1) check the existence of the dependency, 2) install the latest one if not exists.

When specify the version, we can make the version range feature (which is also a constraint) work.

[merusso]

Should this issue be moved to https://github.com/kubevela/kubevela?

[wonderflow]

@merusso Yes, moving

[Hanmengnan]

I agree with @wonderflow's point of view. For addons that dependents other addons, we can specify the version range of other dependent addons in the dependencies field. The system field is used to specify the current addon's dependent system environment. It is not appropriate to place the version range of dependent addons here.

[merusso]

Sorry if I was unclear, but this is what I'm proposing above. I'm proposing that dependencies[].version act as a semver constraint, similar to the system properties.