ProblemStatement

Today when a UDN is created we do the following:

apiVersion: v1
kind: Namespace
metadata:
  name: blue
  labels:
    name: blue
    k8s.ovn.org/primary-user-defined-network: "" ----> IMPORTANT
—
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  name: blue
  labels:
    k8s.ovn.org/bgp-network: ""
  namespace: blue
spec:
  topology: "Layer3"
  layer3:
    role: Primary
    subnets:
    - cidr: 103.103.0.0/16
      hostSubnet: 24
    - cidr: 2014:100:200::0/60
      hostSubnet: 64

without adding that label to the namespace (at the time of creation of namespace - not mutable/not updatable) creation of a UDN won't make that namespace UDN enabled and pods will get attached to the default network. See https://github.com/ovn-kubernetes/ovn-kubernetes/pull/4912 for more details on why we decided to have this.

However in OCP we have a self-service mode

1. https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/project_apis/projectrequest-project-openshift-io-v1
2. https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/building_applications/projects#impersonation-project-creation_creating-project-other-user

so the goal is to also allow users to be able to create UDNs without admin intervention. This is super important for CNV - they heavily rely on self-service mode.

Currently when users use oc project command there is is no way to copy or provide labels over. This is a problem on CLI and using Console. So using this way a UDN workload can never be created by a tenant because the label simply won't exist on the namespace created via oc new project.

Goal of this Card

First step is to write an enhancement into the ocp/enhancements repo that was asked by our ocp leads in the discussion that happened here: https://docs.google.com/document/d/12NTFZUSWCvGdEmxjOFOYV567pl97LQrmiQC-20xdg9I/edit?tab=t.0#heading=h.5fmozssvsjln

See the outcomes:

• Outcome:
• Modifying oc new-project command seems viable.
• Needs feature gate, e2e testing, design. Probably not making 4.18.0.
• We will still require the label as it is needed to avoid the race.

• Workaround proposal:
• A cluster admin could create namespaces with the label by modifying their custom template. This would apply for all namespaces created with the oc new-project command.

Action items

• Update enhancement outlining the discussion here
• Propose new API and coordinate the new command argument

Goal of the enhancement is to solve the problem around how can we make oc new project command take another argument say --request-udn or something which behind the scenes will leverage the templates in ocp to ensure that label get's copied onto the namespace. Same solution should be usable by CNV's console team upalatuc@redhat.com can help here with console side but we must ensure enhancement outlines both.

cc deads@redhat.com had mentioned another alternative on that doc and its good to write those down as well to consider them in the enhancement.

Requirement for the enhancement even though change is small is because change is on other repos. krizza@redhat.com 's team can help us: https://redhat-internal.slack.com/archives/CKJR6200N/p1737144728350019?thread_ts=1737034499.003329&cid=CKJR6200N is the full slack thread discussion

bbennett@redhat.com or trozet@redhat.com : Am I forgetting anything?

rhn-support-misalunk if you are stuck please reach out on udn channel in slack