frobware

bgp-cloud-connector on Azure: who may write the router nodes' NICs

The operator turns on enableIPForwarding on the network interface of each router node. Where forwarding is already on it skips the NIC and writes nothing, so it then needs only networkInterfaces/read on the group holding the NICs. A NIC write is a whole-object PUT, so Azure also checks virtualNetworks/subnets/join/action and loadBalancers/backendAddressPools/join/action on the resources the NIC references.

frobware

bgp-cloud-connector on ARO HCP: what the operator needs if IP forwarding is already on

What	Actions	Group	Needed if forwarding is already on?
Find the Route Server, create and delete the BGP peerings	virtualHubs/read, bgpConnections/read, /write, /delete	customer	yes -- this is the operator's job
Check each router node's NIC	networkInterfaces/read	managed	yes, but reads are not denied
Turn forwarding on	networkInterfaces/write + backendAddressPools/join/action	managed	no -- it skips NICs already on (internal/platform/azure/nodes.go, if nic.IPForwarding { continue })
(linked check on the NIC write)	subnets/join/action	customer	no

frobware

What the operator does	Resource	Lives in	Actions
Find the Route Server, peer and unpeer the router nodes	Route Server and its BGP connections	customer	virtualHubs/read, bgpConnections/read, /write, /delete
Turn on IP forwarding	the router nodes' NICs	managed	networkInterfaces/read, /write
...which also needs join on what the NIC references	the load balancer's backend pool	managed	loadBalancers/backendAddressPools/join/action
	the subnet	customer	virtualNetworks/subnets/join/action

frobware

Title: Advertised layer2 primary UDN drops pod traffic on some nodes until ovnkube-node is restarted

Component: Networking / ovn-kubernetes

Description of problem

If a RouteAdvertisements and the layer2 primary ClusterUserDefinedNetwork it selects are created a few seconds apart, some workers end up advertising the network over BGP but do not forward traffic to its pods. Nothing reports an error: the CUDN is NetworkCreated=True and the RouteAdvertisements is Accepted=True. Restarting ovnkube-node on the worker fixes it.

Version-Release number of selected component

frobware

OpenShift versions in bgp-cloud-connector's e2e jobs

From ci-operator/config/openshift/bgp-cloud-connector/openshift-bgp-cloud-connector-main.yaml in openshift/release, 8 October 2026.

job	how it gets a cluster	OpenShift
e2e-aws, e2e-aws-operator, e2e-aws-fips-operator	ipi-aws from the job's release:latest	4.23 (ocp/4.23 integration)
e2e-azure-operator	ipi-azure, same release	4.23
e2e-gcp-operator	ipi-gcp, same release	4.23
e2e-rosa-operator	ROSA HCP from OCM, OPENSHIFT_VERSION: "4.22", stable channel	4.22

frobware

/* faccessat-trailing-slash-probe.c
 *
 * POSIX pathname resolution requires a path with a trailing slash
 * to resolve only to a directory: syscalls on
 * "symlink-to-regular-file/" must fail with ENOTDIR.
 *
 * macOS 15.7.9 (xnu-11417.140.69.711.44) violates this at the
 * kernel's pathname-resolution layer for the symlink case only: a
 * plain "regular-file/" still fails correctly, but
 * "symlink-to-regular-file/" resolves as if the slash were absent

frobware

Replace the faccessat-with-trailing-slash directory probe in
file_name_completion_dirp with an explicit fstatat + S_ISDIR check.

POSIX says a path ending in "/" must resolve only to a directory;
access(2)-family calls on "symlink-to-regular-file/" must fail with
ENOTDIR. macOS 15.7.9 (xnu-11417.140.69.711.44, kernel built
2026-07-21) violates this at the pathname-resolution layer: for a
symlink whose target is a regular file, faccessat(fd, "link/",
F_OK, AT_EACCESS) returns 0 and even stat("link/") succeeds. A
plain regular file ("file/", no symlink) still fails with ENOTDIR;

frobware

import CommonCrypto
import CSSH2
import Foundation

/// Raw libssh2 operations with no orchestration logic.
///
/// Each method performs a single discrete step (TCP connect,
/// handshake, authenticate, open channel). The TransportDriver
/// calls these in the order dictated by the state machine.
public final class SSHConnection: @unchecked Sendable {

frobware

❯ And how did I advertise the local LAN?

● Let me check the NixOS configuration for tailgate01.

● Searched for 2 patterns, read 1 file (ctrl+o to expand)

● The route is advertised via the services.tailscale-gateway NixOS module at line 50-56. Let me find the module to show you the details.

● Searched for 1 pattern, read 1 file (ctrl+o to expand)

frobware

Konflux bundle coordination problem

Background

The openshift/bpfman-operator repository builds three container images from the same codebase via Konflux:

• bpfman-operator (the operator binary)
• bpfman-agent (the agent DaemonSet binary)
• bpfman-operator-bundle (the OLM bundle)