-
Notifications
You must be signed in to change notification settings - Fork 22
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 kubeconfig secret ref in hypershift deployment status #33
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zhujian7 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Kudos, SonarCloud Quality Gate passed!
|
Is the plan to copy this back to the same namespace as the HypershiftDeployment? In which case there shouldn't be a name collision, or is it copied to the managedCluster Namespace for the ManagementCluster? |
@jnpacker It was copied to the managedCluster Namespace for the ManagementCluster since the addon-agent only has permission to create secret in the managementCluster namespace on the hub. If we want to copy this to the HypershiftDeployment namespace, I think we need to grant the addon-agent permission to create/delete secret in all namespaces on the hub, which is not really safe. |
Are you looking for a review yet? |
This PR is not in a hurry to merge, just wanted to discuss how to deal with these two secrets would be better. |
I like the reference idea then. |
Signed-off-by: zhujian <[email protected]>
bdefe88
to
aaff451
Compare
Kudos, SonarCloud Quality Gate passed!
|
Can we close this out, as its from Mar 7? |
@philipwu08 For https://issues.redhat.com/browse/CMCS-102, do we still need this, if it is not necessary, I will close this PR. |
Signed-off-by: zhujian [email protected]
Now we copied the hosted cluster kubeconfig to the hub cluster in a form of
fmt.Sprintf("%s-admin-kubeconfig", hydName)
, but if the hypershiftDeployment name is too long, I think creating the secret will fail, And if there are two hypershift deployment with the same name but different spec.TargetName, the secret will conflict.Learn from the way hypershift handles hostedcluster, we can record the secret ref into the hypershift deployment status.