Repository navigation
bgp_dt05: generate octavia net-attach-def as macvlan - #4273
Merged
openshift-merge-bot[bot] merged 1 commit intoOct 21, 2026
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
eduolivares
force-pushed
the
feature/bgp-dt05-octavia-macvlan-nad
branch
from
October 20, 2026 11:56
8a443df to
85a294e
Compare
|
/lgtm |
…s macvlan On bgp_dt05 the Octavia management network is a VLAN-23 provider network extended to the Networker nodes. Octavia service pods must attach to it via a macvlan whose master is the host "octavia" VLAN interface, so their traffic egresses onto VLAN 23 toward the OVN provider gateway on the Networkers. Generate the octavia net-attach-def as a macvlan (master "octavia") instead of the default linux-bridge; all other networks keep the bridge type. Also emit per-node octavia_ip: the OCP workers are not assigned an octavia IP in the networking-env-definition, so (like loopback_ip) it is read from the architecture values.yaml via original_content. worker-3 (tester) has no octavia_ip and is skipped. Without this the architecture nncp replacement fails: "fieldPath data.node_3.octavia_ip is missing". This matches the architecture bgp_dt05 change that switches the octavia NAD and NNCP host interface to the VLAN-23 provider design. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Eduardo Olivares <eolivare@redhat.com>
eduolivares
force-pushed
the
feature/bgp-dt05-octavia-macvlan-nad
branch
from
October 21, 2026 07:59
85a294e to
c6cb866
Compare
|
/lgtm |
Contributor
Author
|
verified downstream. Please review. |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: michburk The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Valkyrie00
approved these changes
Oct 21, 2026
openshift-merge-bot
Bot
merged commit Oct 21, 2026
9345b67
into
openstack-k8s-operators:main
13 checks passed
centosinfra-prod-github-app Bot
added a commit
to openstack-k8s-operators/architecture
that referenced
this pull request
Oct 26, 2026
…n-vlan-provider
bgp_dt05: route Octavia mgmt through the VLAN-23 provider network
The merged VLAN-provider staging (lbMgmtNetwork vlan/23 + octavia:br-octavia on the networkers) was incomplete: the OCP-side octavia network was still an in-cluster linux-bridge reached via BGP, and br-octavia had no physical uplink, so Octavia services could not reach the amphorae through the Networker nodes.
Complete the VLAN-23 provider design (validated on titan62, where the LB then reaches ACTIVE/ONLINE):
nncp: make the workers' "octavia" host interface a VLAN-23 sub-interface of the dedicated octavia NIC (enp6s0) instead of a linux-bridge, with per-host IPs (172.23.0.20-22), and route 172.24.0.0/16 via the provider gateway 172.23.0.1 on dev octavia instead of over BGP. worker-3 (tester) keeps reaching octavia mgmt via BGP and gets no octavia interface.
nncp: switch the octavia net-attach-def from a bridge to a macvlan whose master is the "octavia" VLAN interface, so pod traffic egresses onto VLAN 23.
edpm/networkers/r{0,1,2}: add nic1 as the br-octavia trunk member (the bridge previously had no physical uplink). OVN tags VLAN 23 on the localnet, so no VLAN sub-interface or IP is needed on br-octavia.
Note: this requires an octavia-operator that supports lbMgmtNetwork providerNetworkType, deployed before Octavia is first created; otherwise the flat management network persists and must be recreated.
Depends-On: openstack-k8s-operators/ci-framework#4273
Reviewed-by: Andrew Bays <andrew.bays@gmail.com>
Reviewed-by: John Fulton <johfulto@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On bgp_dt05 the Octavia management network is a VLAN-23 provider network extended to the Networker nodes. Octavia service pods must attach to it via a macvlan whose master is the host "octavia" VLAN interface, so their traffic egresses onto VLAN 23 toward the OVN provider gateway on the Networkers.
This updates the
ci_gen_kustomize_valuesbgp_dt05network-valuestemplate to generate the values that design needs:net-attach-defas amacvlan(masteroctavia) instead of the default linux-bridge; all other networks keep the bridge type.octavia_ip. The OCP workers are not assigned an octavia IP in the networking-env-definition, so (likeloopback_ip) it is read from the architecturevalues.yamlviaoriginal_content. worker-3 (tester) has nooctavia_ipand is skipped. Without this the architecture nncp replacement fails withfieldPath data.node_3.octavia_ip is missing.This matches the architecture bgp_dt05 change that switches the octavia NAD and NNCP host interface to the VLAN-23 provider design.
Related: openstack-k8s-operators/architecture#842