search

kubernetes-sigs / cluster-api-provider-vsphere

Apache License 2.0
372 stars 295 forks source link

CAPV, vSphere CPI, and vSphere CSI use different schemas for the vCenter server address #2301

Closed dlipovetsky closed 7 months ago

dlipovetsky commented 1 year ago

/kind bug

What steps did you take and what happened: [A clear and concise description of what the bug is.] cluster-api-provider-vsphere accepts the vCenter server address in host:port concatenated form, e.g. 1.2.3.4:5678, or as a URL, e.g. https://example.com:5678.

On the other hand, both cloud-provider-vsphere, and vsphere-csi expect the vCenter server address as separate host and port values, and do not support the URL.

The CAPV user has to generate configuration for cloud-provider-vsphere and vsphere-csi, so they need to be informed about this difference. Right now, the difference is not documented.

In fact, the current cluster templates generate invalid cloud-provider-vsphere and vsphere-csi configuration if VSPHERE_SERVER is in host:port concatenated form, or is a URL. CAPV deploys the cluster, and the user remains unaware that that CPI and CSI are misconfigured.

https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/9cfdc84c51cfb8f10777036c0a17d772625ebb34/templates/cluster-template.yaml#L35

https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/9cfdc84c51cfb8f10777036c0a17d772625ebb34/templates/cluster-template.yaml#L454

https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/9cfdc84c51cfb8f10777036c0a17d772625ebb34/templates/cluster-template.yaml#L773

What did you expect to happen: One or more of the following: (a) Clearly document this difference between the projects for CAPV end users. (b) Change cloud-provider-vsphere and vsphere-csi to accept a concatenated or URL form. (I'm not sure why the projects don't already do this; internally, they create a URL from the separate host and port fields. See here, and here.)
(c) Change CAPV to accept separate fields for host and port.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

sbueringer commented 1 year ago

cc @lubronzhan @wyike

lubronzhan commented 1 year ago

Yeah if you tried to deploy CPI and CSI through cluster-template in CAPV, you will run into issues. I think the cluster-template.yaml is just a starting point if customer wants to deploy cluster on very basic use case. Maybe we can document more about when the customer wants to use the cluster-template. Also link to the official doc in Cloud-provider-vsphere.

CPI and CSI still use that form probably it used to have the legacy ini form of configuration. CPI could be deployed as a process.

sbueringer commented 1 year ago

@lubronzhan WDYT would it make sense to support the same url field as in CAPV in CSI & CPI as well?

I don't think it makes much sense to add two additional fields to CAPV in all places where we have the URL today

sbueringer commented 1 year ago

WDYT would it make sense to support the same url field as in CAPV in CSI & CPI as well?

@xing-yang What do you think about it from a CPI perspective?

k8s-triage-robot commented 9 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 8 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot commented 7 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 7 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/issues/2301#issuecomment-2022639509): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.