create a proposal for addon dependency management #157

elgnay · 2025-10-22T04:28:09Z

Related issue: #156

openshift-ci · 2025-10-22T04:28:13Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: elgnay
Once this PR has been reviewed and has the lgtm label, please assign qiujian16 for approval. For more information see the Code Review Process.

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

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

qiujian16 · 2025-10-22T07:31:37Z

enhancements/sig-architecture/156-addon-dependency/README.md

+    // The default is false (soft dependency).
+    // +optional
+    // +kubebuilder:default=false
+    Required bool `json:"required,omitempty"`


boolean needs to be avoided.

Replaced Required with Type, using explicit values "Optional" and "Required".

qiujian16 · 2025-10-22T07:33:13Z

enhancements/sig-architecture/156-addon-dependency/README.md

+
+- **Soft dependencies (default, required=false)**: The addon can still function with reduced functionality when the dependency is missing. When a soft dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `DependencyNotSatisfied`, but the klusterlet-agent will not modify the `Available` condition, allowing the addon to remain available if its health checks pass.
+
+- **Hard dependencies (required=true)**: The addon cannot function at all without the dependency. When a hard dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `RequiredDependencyNotSatisfied`, and the klusterlet-agent will detect this specific reason and set `Available=False`.


I think the addon will not be deployed under this case, like we should have a status that condition are or met, then addon-framework will deploy the resource.

I think the addon will not be deployed under this case

Should this work on a fresh install only, or rollout as well?

If the addon is already installed and its dependent addon becomes unavailable, should the addon be uninstalled in that case?

I do not think so, but we should have a degrade condition with the message that some dependencies are missing. With the second thought, maybe we do not need to disable installation, a degraded status condition will be good.

zhujian7 · 2025-10-27T01:28:26Z

enhancements/sig-architecture/156-addon-dependency/README.md

+    // An empty list means the add-on has no dependencies.
+    // The default is an empty list.
+    // +optional
+    Dependencies []AddonDependency `json:"dependencies,omitempty"`


I'm not sure if there is a case: for one addon, it has different dependencies on different type of managed clusters, for instance, on the OCP clusters it depends on the managed-serviceaccount addon, but on the eks clusters, it does not or even depends on other addons. I am asking because we have a similar case for the addon health checking recently.

At present, we don’t have such a requirement, and we aim to keep the initial design as simple as possible. The case you mentioned is very interesting. In the future, the current API could be extended by adding a new field in AddonDependency — for example, when — that allows specifying a CEL expression to determine whether an addon actually depends on another.

qiujian16 · 2025-11-05T08:46:55Z

/assign @jnpacker

jnpacker · 2025-11-05T21:07:28Z

enhancements/sig-architecture/156-addon-dependency/README.md

+### Non-Goals
+
+- Automatic installation of dependencies (users still need to explicitly install required addons)
+- Dependency resolution and ordering during installation


I assume this means if you have two dependencies set there is not ordering of the two dependencies. If you want ordering then you create a chain of dependent addons?

Yes, that’s right. There’s no implicit ordering between multiple dependencies — creating a dependency chain is the way to enforce sequence.

jnpacker · 2025-11-05T21:10:21Z

enhancements/sig-architecture/156-addon-dependency/README.md

+
+There are two types of dependencies:
+
+- **Optional dependencies (default, type=Optional)**: The addon can still function with reduced functionality when the dependency is missing. When an optional dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `DependencyNotSatisfied`, but the klusterlet-agent will not modify the `Available` condition, allowing the addon to remain available if its health checks pass.


Do we have any examples of this?
Will you publish some type of warning message in this case?

Do we have any examples of this?

The work-manager is one of the MultiCluster Engine add-ons. Its pod log viewing feature depends on the managed-serviceaccount add-on. If that add-on is missing, other features—such as cluster view and cluster action—will still work.

Will you publish some type of warning message in this case?

Added an optional field, message, to capture this type of warning or informational message.

jnpacker · 2025-11-05T21:12:08Z

enhancements/sig-architecture/156-addon-dependency/README.md

+    description: "An addon that optionally uses ManagedServiceAccount API"
+  dependencies:
+  - name: managed-serviceaccount
+    # type: Optional is the default, can be omitted


I was going to say that optional is default, but without any other type of cue, I would have expected it to be optional: false from just reading the keys. you have.

That makes sense. Changed the default from Optional to Required.

jnpacker · 2025-11-05T21:14:16Z

enhancements/sig-architecture/156-addon-dependency/README.md

+    //   condition should be set to False when the dependency is not satisfied.
+    // +optional
+    // +kubebuilder:validation:Enum=Optional;Required
+    // +kubebuilder:default=Optional


I'm not sure I would have assumed it was optional by default.

Also do we need or want to consider any versioning semantics?

I'm not sure I would have assumed it was optional by default.

Changed the default from Optional to Required.

Also do we need or want to consider any versioning semantics?

Since the ClusterManagementAddOn itself does not include any add-on version information, it’s not possible to define dependencies based on specific versions.

Signed-off-by: Yang Le <[email protected]>

openshift-ci bot requested review from deads2k and qiujian16 October 22, 2025 04:28

qiujian16 reviewed Oct 22, 2025

View reviewed changes

elgnay force-pushed the addon-dependency branch from 03d652c to 8954e74 Compare October 22, 2025 08:34

zhujian7 reviewed Oct 27, 2025

View reviewed changes

openshift-ci bot assigned jnpacker Nov 5, 2025

jnpacker reviewed Nov 5, 2025

View reviewed changes

create a proposal for addon dependency management

4624636

Signed-off-by: Yang Le <[email protected]>

elgnay force-pushed the addon-dependency branch from 8954e74 to 4624636 Compare November 6, 2025 15:36


		- Soft dependencies (default, required=false): The addon can still function with reduced functionality when the dependency is missing. When a soft dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `DependencyNotSatisfied`, but the klusterlet-agent will not modify the `Available` condition, allowing the addon to remain available if its health checks pass.

		- Hard dependencies (required=true): The addon cannot function at all without the dependency. When a hard dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `RequiredDependencyNotSatisfied`, and the klusterlet-agent will detect this specific reason and set `Available=False`.


		There are two types of dependencies:

		- Optional dependencies (default, type=Optional): The addon can still function with reduced functionality when the dependency is missing. When an optional dependency is not satisfied, the addon-manager will set `Degraded=True` with reason `DependencyNotSatisfied`, but the klusterlet-agent will not modify the `Available` condition, allowing the addon to remain available if its health checks pass.

create a proposal for addon dependency management #157

Are you sure you want to change the base?

create a proposal for addon dependency management #157

Conversation

elgnay commented Oct 22, 2025

Uh oh!

openshift-ci bot commented Oct 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qiujian16 Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qiujian16 commented Nov 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elgnay Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elgnay Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

qiujian16 Oct 29, 2025 •

edited

Loading

elgnay Nov 6, 2025 •

edited

Loading

elgnay Nov 6, 2025 •

edited

Loading