Add OCP nodes peer_asn to BGP networking values (test eBGP)

[m-blue-m]

Add bgp_dt02 eBGP architecture with standalone EDPM values

Add bgp_dt02 directory fully independent from bgp_dt01. Replaces
symlinks (control-plane, r0 computes/networkers, deployment) with
standalone copies to avoid inheriting dt01's native-ovn-bgp migration.
dt02 intentionally keeps ovn-bgp-agent; migration to native-ovn-bgp
is a separate follow-up task.

eBGP rack nodes (r1/r2 computes/networkers) set:
  edpm_frr_bgp_asn: 64899 (shared eBGP node ASN, separate from
    leaf ASN range 64999-64900 to avoid collision)
  edpm_ovn_bgp_agent_bgp_as: 64899 (must match FRR main router
    ASN, otherwise agent fails to configure VRF leak routes)
  edpm_frr_bgp_graceful_shutdown: false (RFC 8326, not applicable
    for eBGP nodes during normal operation)
  edpm_frr_bgp_uplinks_scope: external (eBGP peering with leaves)
  edpm_frr_bgp_neighbor_ttl_security_hops: 0 (disable GTSM for
    eBGP since leaves send default TTL)

OCP worker MetalLB peer_asn set per node to match each rack's
leaf ASN (64999/64998/64997).

Related: [OSPRH-28085](https://redhat.atlassian.net/browse/OSPRH-28085)
Assisted-By: Claude Code
Signed-off-by: Maor Blaustein <mblue@redhat.com>

Depends-On: openstack-k8s-operators/ci-framework#4069
(Generate peer_asn in the template for architecture validation gates)

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/8d8a274e511346f7bbaf67e6f31f864a

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 35s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/2ffe2e768f3a40ae95f0991a5e7aaecc

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 07s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/0be9fa127c2749e78c88ebd0e9812e5a

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 06s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/964578c1c02c4120a68975e4cd34aa73

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 32s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/7606dfe81ead49d5b9b5b2b5073eff30

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 39s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/533367b77213464bb40b3e0898c0cb16

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 3m 41s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/5ab99f70ff0a4c8b96fe952ca6afca05

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt01 FAILURE in 4m 44s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/deb897d58e6e4634906216859b21e2e9

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt02 FAILURE in 4m 18s

[centosinfra-prod-github-app]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/b9a0480a20084d05aecd03e51da6a1a1

✔️ noop SUCCESS in 0s
❌ rhoso-architecture-validate-bgp_dt02 FAILURE in 4m 14s

[centosinfra-prod-github-app]

This change depends on a change that failed to merge.

Change openstack-k8s-operators/ci-framework#4069 is needed.

[m-blue-m]

recheck new fix for mocks in gates

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: eduolivares, m-blue-m
Once this PR has been reviewed and has the lgtm label, please assign fultonj for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[abays]

I performed an analysis of this to examples/dt/bgp_dt01, and it revealed that this new DT is 72% identical to the old one, with variations mainly appearing in the values.yaml files (as one would expect). It would be preferable if the common components of bgp_dt01 and bgp_dt02 could be moved to some sort of common directory structure that could then be utilized by both of them. This would significantly reduce the size of these DTs by thousands of lines, thus helping keep the repo DRY. It would also reduce having to duplicate fixes/changes to both DTs if for some reason a common configuration shared between the two needed attention.

I'm not necessarily saying this is a blocking concern at the moment, however. It would be good to get @fultonj 's opinion on this as well.

[abays]

Here's a list of the duplicate code, to help others understand. These files are byte-for-byte identical to dt01:

  - control-plane/kustomization.yaml (208 lines)
  - control-plane/networking/nncp/kustomization.yaml (724 lines — the largest file)
  - control-plane/networking/nncp/ocp_worker_nodes_nncp.yaml (28 lines)
  - control-plane/networking/designateext_metallb.yaml (11 lines)
  - control-plane/networking/metallb_bgppeers.yaml (112 lines)
  - control-plane/networking/ocp_network_template.yaml (8 lines)
  - All 6 edpm kustomization.yaml files (computes + networkers r0/r1/r2)
  - edpm/deployment/kustomization.yaml
  - metallb/kustomization.yaml

[m-blue-m]

I performed an analysis of this to examples/dt/bgp_dt01, and it revealed that this new DT is 72% identical to the old one, with variations mainly appearing in the values.yaml files (as one would expect). It would be preferable if the common components of bgp_dt01 and bgp_dt02 could be moved to some sort of common directory structure that could then be utilized by both of them. This would significantly reduce the size of these DTs by thousands of lines, thus helping keep the repo DRY. It would also reduce having to duplicate fixes/changes to both DTs if for some reason a common configuration shared between the two needed attention.

I'm not necessarily saying this is a blocking concern at the moment, however. It would be good to get @fultonj 's opinion on this as well.

Thank you for checking it.

Prior to this change there were many symlinks used between dt01 and dt02, since I needed to change many things to be different with eBGP than dt01 I tore down some of these symlinks and still found it confusing
and accidentally broke code for dt01 when adjusting dt02 for eBGP needs.

Later when Edu merged migrating dt01 to native OVN BGP (instead of ovn bgp agent), the eBGP changes broke easily (the other way around).
At that point it seemed reasonable to me to make fuller separation without symlinks used, sparing CI from breaking that easy for any change affecting BGP jobs at least.

Not sure what is the most right approach, maybe there are more ways to classify common code by file/dir name and store elsewhere, without the confusing symlinks which can easily break one of the jobs, and if
needed uniquely could be moved to specific job dir.
Due to eBGP changes and some mutually exclusive FRR configurations (graceful-shutdown, route-reflector-client, different ASNs per rack), the two DTs are expected to diverge further rather than converge.

[fultonj]

I have three comments so far. The first is a request for a change and the second two are observations which might be useful for other reviewers.

1. There are no markdown files

The root directory does not have README.md (or other markdown files).

When I go to the following I see readme files which tell me how to use this architecture.

https://github.com/openstack-k8s-operators/architecture/tree/main/examples/dt/bgp_dt01

We need the same for bgp_dt02. I should be able to:

1. clone this repo
2. read the linked .md files
3. be able to run kustomize commands to generate the CRs

I don't think we should merge until we have the missing markdown documentation.

2. CRs build fine

I was able build all of the CRs are defined in automation/vars/bgp_dt02.yaml and I see it's a lot like bgp_dt01:

┌───────────────────────────────────┬────────────────────────────┬─────────────────────────────────────┐
│               File                │           Stage            │             Description             │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 01_nncp.yaml                      │ nncp-configuration         │ Node Network Configuration Policies │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 02_networking.yaml                │ networking                 │ MetalLB and broader networking      │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 03_control-plane.yaml             │ control-plane              │ OpenStackControlPlane CR            │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 04_edpm-r0-compute-nodeset.yaml   │ edpm-computes-r0-nodeset   │ Rack 0 compute nodeset              │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 05_edpm-r1-compute-nodeset.yaml   │ edpm-computes-r1-nodeset   │ Rack 1 compute nodeset              │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 06_edpm-r2-compute-nodeset.yaml   │ edpm-computes-r2-nodeset   │ Rack 2 compute nodeset              │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 07_edpm-r0-networker-nodeset.yaml │ edpm-networkers-r0-nodeset │ Rack 0 networker nodeset            │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 08_edpm-r1-networker-nodeset.yaml │ edpm-networkers-r1-nodeset │ Rack 1 networker nodeset            │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 09_edpm-r2-networker-nodeset.yaml │ edpm-networkers-r2-nodeset │ Rack 2 networker nodeset            │
├───────────────────────────────────┼────────────────────────────┼─────────────────────────────────────┤
│ 10_edpm-deployment.yaml           │ edpm-deployment            │ Dataplane deployment                │
└───────────────────────────────────┴────────────────────────────┴─────────────────────────────────────┘

[johfulto@laptop CRs{diff_asn_test_ebgp}]$ wc -l *.yaml
  527 01_nncp.yaml
  513 02_networking.yaml
  608 03_control-plane.yaml
  195 04_edpm-r0-compute-nodeset.yaml
  200 05_edpm-r1-compute-nodeset.yaml
  200 06_edpm-r2-compute-nodeset.yaml
  185 07_edpm-r0-networker-nodeset.yaml
  190 08_edpm-r1-networker-nodeset.yaml
  190 09_edpm-r2-networker-nodeset.yaml
   13 10_edpm-deployment.yaml
 2821 total
[johfulto@laptop CRs{diff_asn_test_ebgp}]$ 

3. diff bgp_dt01 bgp_dt02

I built the CRs for bgp_dt01 and bgp_dt02 and then diff'd them:

https://gist.github.com/fultonj/09d8fe63a7333b441843e380b2a532d9

The above should help other reviewers.

[fultonj]

The ØØ characters make this an invalid IP address. Can you change it to 192.168.123.1?

[fultonj]

This PR directly copies a lot of files from bgp_dt01.

A similar thing is going on in a new PR for bgp_dt05

I asked an LLM to refactor 01, 02, and 05 by sharing a common directory for bgp. Links to refactored code and analysis are available in this gist. Thoughts?

https://gist.github.com/fultonj/bf885c3b065988854b1b7da6eeb0a523