Feature Overview

Server foundation introduced the API addonDeplymentConfig and clusterManagementAddon for users to configure how to deploy an addon.

For example, the following config will make the work manager addon be deployed in the `open-cluster-management-agent-addon`(default value) namespace on all clusters selected by the global placement:

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ClusterManagementAddOn
metadata:
 name: work-manager
 annotations:
   "addon.open-cluster-management.io/lifecycle": "addon-manager"
spec:
  addOnMeta:
    displayName: work-manager
    description: "work-manager provides action, view and rbac settings"
  supportedConfigs:
  - group: addon.open-cluster-management.io
    resource: addondeploymentconfigs
  installStrategy:
    type: Placements
    placements:
      - name: global
        namespace: open-cluster-management-global-set

If users want to make it in another namespace(`my-addons`) and tolerant some taints, users can add an addDeploymentConfig, and reference it in the clusterManagementAddon.

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ClusterManagementAddOn
metadata:
 name: work-manager
 annotations:
   "addon.open-cluster-management.io/lifecycle": "addon-manager"
spec:
  addOnMeta:
    displayName: work-manager
    description: "work-manager provides action, view and rbac settings"
  supportedConfigs:
  - group: addon.open-cluster-management.io
    resource: addondeploymentconfigs
    defaultConfig:                                        // add the default config
      name: my-addon-deploy-config
      namespace: multicluster-engine
  installStrategy:
    type: Placements
    placements:
      - name: global
        namespace: open-cluster-management-global-set


apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: my-addon-deploy-config
  namespace: multicluster-engine
spec:
  agentInstallNamespace: my-addons
  nodePlacement:
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      operator: Exists

This is just an example, we also have some other fields(addonDeploymentConfig, clusterManagementAddon) that users can configure. We need a mechanism is needed to prevent the resource from being changed back after the user changes it.

Goals

This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature

• …

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

This Section:

• Main success scenarios - high-level user stories
• Alternate flow/scenarios - high-level user stories
• ...

Questions to answer

• ...

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• ...

Customer Considerations

• ...

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?