[Multitenancy] : Add MT PodNetworkConfig CRD #2111
Conversation
aggarwal0009
changed the title
aggarwal0009
changed the title
aggarwal0009
force-pushed
the
ankaggar/MTPC-CRD
branch
from
838e5b5 to
d931cb8
Compare
| } | ||
|
|
||
| // SetOwnerRef sets the controller of the MultitenantPodNetworkConfig to the given object atomically, using HTTP Patch. | ||
| // Deprecated: SetOwnerRef is deprecated, use the more correctly named SetControllerRef. |
There was a problem hiding this comment.
Let's not add a new function that's already deprecated
| } | ||
|
|
||
| // PatchSpec performs a server-side patch of the passed MultitenantPodNetworkConfigSpec to the MultitenantPodNetworkConfig specified by the NamespacedName. | ||
| func (c *Client) PatchSpec(ctx context.Context, key types.NamespacedName, spec *v1alpha1.MultitenantPodNetworkConfigSpec, fieldManager string) (*v1alpha1.MultitenantPodNetworkConfig, error) { |
There was a problem hiding this comment.
is this necessary? MTPNC will get created with known values for spec and I don't expect the spec to need to get updated
|
|
||
| // UpdateSpec does a fetch, deepcopy, and update of the MultitenantPodNetworkConfig with the passed spec. | ||
| // Deprecated: UpdateSpec is deprecated and usage should migrate to PatchSpec. | ||
| func (c *Client) UpdateSpec(ctx context.Context, key types.NamespacedName, spec *v1alpha1.MultitenantPodNetworkConfigSpec) (*v1alpha1.MultitenantPodNetworkConfig, error) { |
There was a problem hiding this comment.
also I think this func is not needed for same reason as above
thatmattlong
left a comment
thatmattlong
left a comment
There was a problem hiding this comment.
let's not add the helper funcs to the client which mutate the spec until we know we need them
aggarwal0009
force-pushed
the
ankaggar/MTPC-CRD
branch
from
03c295b to
f2172d8
Compare
| @@ -0,0 +1,3 @@ | |||
| # MultitenantPodNetworkConfig CRDs | |||
|
|
|||
| MPNC objects represent the network configuration goal state for a pod running a multitenant networked container and are created and managed by control plane as part of the network configuration, during Pod lifecycle events. | |||
There was a problem hiding this comment.
I would also add that it is created by AKS Customers. So any change in the CRD definition has to be backward compatible.
There was a problem hiding this comment.
MPNC object will be created by the swift control plane, though - the crds created by the AKS customers will be on a separate PR. The point on backward compat is valid, but the interface is between CNS and control plane.
| // MultitenantPodNetworkConfigStatus defines the observed state of PodNetworkConfig | ||
| type MultitenantPodNetworkConfigStatus struct { | ||
| // network container id | ||
| UUID string `json:"uuid,omitempty"` |
There was a problem hiding this comment.
Lets call it NCId only or CompartmentId
crd/multitenantpodnetworkconfig/api/v1alpha1/multitenantpodnetworkconfig.go
Show resolved
Hide resolved
crd/multitenantpodnetworkconfig/api/v1alpha1/multitenantpodnetworkconfig.go
Show resolved
Hide resolved
|
|
||
| // MultitenantPodNetworkConfig is the Schema for the multitenantpodnetworkconfigs API | ||
| // +kubebuilder:resource:scope=Namespaced | ||
| // +kubebuilder:resource:shortName=mpnc |
There was a problem hiding this comment.
suggest mtpnc for shotname since that's what we've been saying out loud
aggarwal0009
force-pushed
the
ankaggar/MTPC-CRD
branch
from
d686552 to
38b48b6
Compare
aggarwal0009
force-pushed
the
ankaggar/MTPC-CRD
branch
from
38b48b6 to
ca12e0f
Compare
Reason for Change:
New CRD MultitenantPodNetworkConfig added to enable VNET multitenancy – which will be watched and managed by the control plane.
Issue Fixed:
Requirements:
Notes: