Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate the field of managedclusteraddon.spec.installNamespace #298

Open
zhujian7 opened this issue Oct 24, 2023 · 3 comments
Open

Deprecate the field of managedclusteraddon.spec.installNamespace #298

zhujian7 opened this issue Oct 24, 2023 · 3 comments

Comments

@zhujian7
Copy link
Member

zhujian7 commented Oct 24, 2023

Now we can use the managedclusteraddon.spec.installNamespace field to set which namespace the addon agent will be deployed on the managed clusters. But there are some disadvantages, like using managedclusteraddon.spec.installNamespace, the value is determined by the addon deployer, not the developer, so for example, if you want to use the addon's installStrategy feature(the ManagedClusterAddon will be created automatically), the value cannot be configured and can only be the default value open-cluster-management-agent-addon

So we are exploring a more general way to set up this install namespace; In OCM, when we develop an OCM addon, we only need to implement the AgentAddon interface:

  • we can use the Manifests function to define what resources we want to deploy into the managed cluster, there might be some namespace scoped resources, like deployments, let it call the namespace manifests-namespace;
  • if the addon agent also wants to access the hub cluster, we can use the Registration to configure how to access hub, and a config func AgentInstallNamespace is provided to config the registration credential namespace, so when the addon is deployed, there will be a hub kubeconfig secret generated in this namespace, and the deployments can use this secret to access the hub cluster. let it call this namespace registration-namespace;

The manifests-namespace and the registration-namespace can be totally decided by the addon developer, for example, in the above two functions you can write code to read the namespace from the API addondeploymentconfig.spec.agentInstallNamespace or make it a fixed value like test-ns or any other way. No matter which way, they should be the same value. And the value will be shown in the field managedclusteraddon.status.namespace.
With this, the managedclusteraddon.spec.installNamespace is not required, using the installStrategy feature will not always deploy the agent into the open-cluster-management-agent-addon namespace as well.

Copy link

This issue is stale because it has been open for 120 days with no activity. After 14 days of inactivity, it will be closed. Remove the stable label to prevent this issue from being closed.

@github-actions github-actions bot added the Stale label Feb 25, 2024
@zhujian7 zhujian7 removed the Stale label Feb 26, 2024
mprahl pushed a commit to mprahl/OCM that referenced this issue Mar 14, 2024
Copy link

This issue is stale because it has been open for 120 days with no activity. After 14 days of inactivity, it will be closed. Remove the stable label to prevent this issue from being closed.

@github-actions github-actions bot added the Stale label Jun 26, 2024
@qiujian16 qiujian16 removed the Stale label Jul 10, 2024
Copy link

github-actions bot commented Nov 7, 2024

This issue is stale because it has been open for 120 days with no activity. After 14 days of inactivity, it will be closed. Remove the stable label to prevent this issue from being closed.

@github-actions github-actions bot added the Stale label Nov 7, 2024
@qiujian16 qiujian16 removed the Stale label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants