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

Add post-join actions after child cluster joins in parent cluster successfully. #742

Open
lmxia opened this issue Sep 20, 2023 · 2 comments
Labels
kind/feature New feature or request

Comments

@lmxia
Copy link
Contributor

lmxia commented Sep 20, 2023

What would you like to be added:

I would like clusternet could support a mechanism to trigger some actions like chart install after child cluster join successfully.

Post actions may support default settings or custom setting.

Why is this needed:

After the child cluster join into it's parent, we need some init-package most likely helm charts to be installed.

@lmxia lmxia added the kind/feature New feature or request label Sep 20, 2023
@dixudx
Copy link
Member

dixudx commented Sep 21, 2023

I wonder whether it is feasible to use a predefined Subscription that matches all clusters (or a group of selected clusters with specific labels, name prefixes, etc) to help deploy all needed dependencies/initializations (aka post-install). On this occasion, such a Subscription is working like a DaemonSet. This is exactly how CNI plugins are initialized/installed for any new joined nodes.

Clusternet has the capability to deploy any objects to matching child clusters. We could follow the same principle of CNI installation to help us finish all the post-join actions for child clusters.

@dixudx
Copy link
Member

dixudx commented Sep 25, 2023

After discussion, we thought it would be better to add a condition for ManagedCluster to indicate the result/status of post-join steps. And this condition could be used to represent whether the clusters are ready/not-ready for scheduling.

For our predefined Subscription objects, we could add tolerations for scheduling.

Here there are several remaining issues to be considered.

  • Backwards compatibility. How should we apply those predefined Subscription objects to existing already-joined clusters?
  • The orders. What would happen if we add a new Subscription object for post-join actions?
  • Will multiple such Subscription objects result in action conflicts, cluster status flapping, etc?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants