Conversation
This PR introduces the NetworkTopologyProvider CRD framework for vSphere Supervisor networking configuration. A NetworkTopologyProvider Custom Resource represents the type of Network Topology supported by this Supervisor. The term 'topology' is used to avoid terminology conflict with notion of 'network provider' inside a Network CR, which represents (loosely) the vim network backing the Supervisor Network object. 3 different providers exist, but not all 3 providers may be supported by every Supervisor at a given time. These providers include: - nsx_container_plugin: Tier-1 gateways per namespace - nsx_vpc: VPC topology for Supervisor. - vsphere_networking vSphere: VDS-backed networking Changes Add base NetworkTopologyProvider CRD with type enum and provider reference Add NCPNetworkTopologyProvider for NSX Container Plugin (Tier-1 per namespace) topology Add NSXTVPCNetworkTopologyProvider for NSX VPC topology Add VSphereNetworkTopologyProvider for vSphere Distributed Switch topology Fix hack/client-gen.sh to work with Go 1.18+ module mode by adding --output-base flag
| // NetworkTopologyProviderTypeNSXT is the provider type for NSX Container Plugin Tier1-per-namespace network | ||
| // topology. | ||
| NetworkTopologyProviderTypeNSXT NetworkTopologyProviderType = "nsx_container_plugin" | ||
| // NetworkTopologyProviderTypeVDS is the provider type for vSphere Networking topology. | ||
| NetworkTopologyProviderTypeVDS NetworkTopologyProviderType = "vsphere_network" | ||
| // NetworkTopologyProviderTypeNSXTVPC is the provider type for NSX-T VPC network topology. | ||
| NetworkTopologyProviderTypeNSXTVPC NetworkTopologyProviderType = "nsx_vpc" |
There was a problem hiding this comment.
I could not find the same parallels you describe. The closest I could find was here:
https://github.com/vmware-tanzu/net-operator-api/blob/master/api/v1alpha1/network_types.go#L48-L60
I think we should either retain precise mappings, or wholesale new ones, in which case if new, I would opt for something like:
nsx-t1vsphere-networkingnsx-vpc
or something similar.
There was a problem hiding this comment.
Another note - I'm not sure if it's allowed, but there is nothing that uses nsx-t_vpc today, so if we did have the opportunity to rename that to nsx-vpc, that would be desirable.
There was a problem hiding this comment.
This is in fact not the most recent change I made, which I seemed to have lost and ended up pushing the wrong commit. Indeed I was aiming to match those strings in network_types.go, Ian. I thought I had changed these to match, but looks like I lost that change. Will update.
Regarding changing https://github.com/vmware-tanzu/net-operator-api/blob/master/api/v1alpha1/network_types.go#L59 to nsx_vpc, I need to defer to @bryanv @fstrudel.
yahhhya
force-pushed
the
topic/yc004606/VKAL-36509-networktopoprovider-crd
branch
from
962ca42 to
1c9caaf
Compare
| // Name is the name of resource being referenced. | ||
| Name string `json:"name"` | ||
| // API version of the referent. | ||
| APIVersion string `json:"apiVersion,omitempty"` |
There was a problem hiding this comment.
Does this not already include the APIGroup ?
There was a problem hiding this comment.
I have dropped this in favor of upstream and generic TypedObjectReference, which does not include apiVersion. I do not think the concrete version specification is necessary. I am open to feedback here.
- Make all NetworkTopologyProvider types cluster-scoped (NetworkTopologyProvider, NSXTNetworkTopologyProvider, NSXTVPCNetworkTopologyProvider, VSphereDistributedNetworkTopologyProvider) - Remove +genclient markers to stop generating clientset/listers/informers - Rename NetworkTopologyProviderReference to TypedObjectReference and remove redundant APIVersion field (keep only APIGroup/Kind/Name per k8s conventions) - Rename NetworkTopologyProviderType to NetworkTopologyType for future reuse in NetworkTopology CRD - Standardize shortNames: ntp, nsxtntp, nsxtvpcntp, vdsntp - Fix kubebuilder validation enum to match actual type values
3 participants
This PR introduces the NetworkTopologyProvider CRD framework for vSphere Supervisor networking configuration.
A NetworkTopologyProvider Custom Resource represents the type of Network Topology supported by this Supervisor. The term 'topology' is used to avoid terminology conflict with notion of 'network provider' inside a Network CR, which represents (loosely) the vim network backing the Supervisor Network object.
3 different providers exist, but not all 3 providers may be supported by every Supervisor at a given time. These providers include:
Changes