The tower server shouldn't update the cluster.status

[swiftslee]

What's it about?
Currently, when cluster.spec.connection.type is proxy, the tower server updates the cluster.status filed, and the cluster controller determines if the cluster is ready according to the status.

What's the reason why we need it?
Actually, the tower server shouldn't update the cluster.status filed.
The cluster controller can try to connect to the proxy service, determines if the cluster is ready by the response HTTP code.
This proposal can reduce the complexity between tower server and clsuter-controller.
/area multicluster
/kind feature-request

[lxm]

kubernetesAPIEndpoint
kubernetesAPIServerPort
kubesphereAPIEndpoint
kubesphereAPIServerPort

It may be a good choice to manage the above fields in tower

[calvinyv]

/assign @yuswift pls take a look

[ks-ci-bot]

@calvinyv: GitHub didn't allow me to assign the following users: pls, take, a, look.

Note that only kubesphere members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @yuswift pls take a look

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lxm]

On the other hand, the creation of the service mc-xxxx is best placed in the tower

[swiftslee]

kubernetesAPIEndpoint
kubernetesAPIServerPort
kubesphereAPIEndpoint
kubesphereAPIServerPort

It may be a good choice to manage the above fields in tower

LGTM. @zryfish

[zryfish]

yeah, agreed

[swiftslee]

/milestone 3.1.0

[zryfish]

@yuswift Any update on this issue?