Skip to content

Add PreExistingVPCNetworkConfigAnnotation - #62

Draft
ihgann wants to merge 1 commit into
vmware-tanzu:masterfrom
ihgann:topic/ig010188/vkal-40713-adopt-brownfield-vpc-netcfg
Draft

Add PreExistingVPCNetworkConfigAnnotation#62
ihgann wants to merge 1 commit into
vmware-tanzu:masterfrom
ihgann:topic/ig010188/vkal-40713-adopt-brownfield-vpc-netcfg

Conversation

@ihgann

@ihgann ihgann commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Add a new annotation, netoperator.vmware.com/vpc-network-configuration, to indicate that when a NamespaceNetworkConfiguration is created with provider type vpc and this annotation is set, the VPCNetworkConfiguration that is referenced will be taken over ownership by the LCM controller of this NamespaceNetworkConfiguration, instead of the default flow of constructing our own, new, VPCNetworkConfiguration.

The intention of this is to handful brownfield cases where Net Operator should start to take ownership of network contracts, but previous Supervisors already maintain a VPCNetworkConfiguration that was previously LCM'd elsewhere.

Constraints:

  • This annotation may only be set at CREATE of the NamespaceNetworkConfiguration, when provider type is vpc.
  • After application, the spec from the NamespaceNetworkConfiguration becomes source-of-truth, and the spec of the associated VPCNetworkConfiguration will become reconciled to reflect the state of the existing NamespaceNetworkConfiguration.

Add the constant that NamespaceNetworkConfiguration reacts to for
adopting a pre-existing VPCNetworkConfiguration named ahead of the
NNC, instead of always creating one named after the NNC itself.
Needed for brownfield namespaces migrating from the legacy
wcpsvc/VCDB path.

Bug number: VKAL-40713

AI-Tool-Used: claude
AI-Model-Used: claude-sonnet-5
AI-Tool-Use-Level: high
AI-Code-Category: production
AI-Time-Saved: 1

Testing Done: go build ./...
// otherwise auto-create (named after this resource). This supports brownfield
// namespaces whose VPCNetworkConfiguration was provisioned before adoption by
// this NamespaceNetworkConfiguration.
PreExistingVPCNetworkConfigAnnotation = "netoperator.vmware.com/vpc-network-configuration"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current key name "netoperator.vmware.com/vpc-network-configuration" is somewhat generic and doesn't clearly reflect the adoption/brownfield intent.

Could we consider renaming it to something more explicit and self-documenting? For example:

  • "netoperator.vmware.com/adopt-vpc-network-configuration"
  • "netoperator.vmware.com/pre-existing-vpc-network-configuration"

// for net-operator's VPC reconciler to adopt in place of the CR it would
// otherwise auto-create (named after this resource). This supports brownfield
// namespaces whose VPCNetworkConfiguration was provisioned before adoption by
// this NamespaceNetworkConfiguration.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since modifying or deleting this annotation after successful reconciliation could lead to unintended VPC overrides or recreate loops, we should enforce its immutability.

Can we add a CEL (Common Expression Language) XValidation rule directly on the CRD struct NamespaceNetworkConfiguration, or enforce this via a validating webhook to reject any UPDATE calls that attempt to change/remove this annotation?

Draft CEL Rule Example (optional to append):
// +kubebuilder:validation:XValidation:rule="oldSelf.metadata.annotations.exists(x, x == 'netoperator.vmware.com/vpc-network-configuration') ? self.metadata.annotations['netoperator.vmware.com/vpc-network-configuration'] == oldSelf.metadata.annotations['netoperator.vmware.com/vpc-network-configuration'] : true",message="The pre-existing VPC network configuration annotation is immutable once set"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants