wido opened a new pull request, #13758:
URL: https://github.com/apache/cloudstack/pull/13758

   ### Description
   This Pull Request adds a new guest network type in which the hypervisor 
performs L3 routing for the Instance: no Virtual Router, no NAT and no DHCP. 
Each Instance receives a public IPv4 address as a /32 and/or an IPv6 address as 
a /128, with a shared, host-independent gateway (169.254.0.1 and fe80::1) that 
every hypervisor carries on the network's bridge. All addressing reaches the 
Instance exclusively via ConfigDrive/cloud-init; a routing daemon on the host 
(FRR, BIRD, ...) advertises the addresses to the fabric and is deliberately out 
of scope for CloudStack.
   
   #### Management server
   - GuestType.L3; the guest_type column is char(32), so no schema change.
   - Offering validation: UserData via ConfigDrive is mandatory, Dns optional 
but ConfigDrive-only, SecurityGroup permitted (now allowed for L3 alongside 
Shared), Dhcp rejected as not supported and not needed. Network mode, 
specifyVlan and VPC use are rejected.
   - DirectRoutedNetworkGuru subclasses DirectNetworkGuru, inheriting the 
Shared-network address lifecycle. canHandle() selects on the offering's guest 
type alone; design() produces a Native broadcast domain with no isolation id. 
After allocation the NicProfile is forced into host-route form, which is also 
the signature by which the agent and ConfigDrive recognise these NICs.
   - createNetwork treats L3 like Shared for the subnet: explicit IP range 
mandatory, vlan/IP-range row created at network creation, IPv6 accepted without 
the /64 restriction, aclType Account.
   - Zone-wide IPv4 overlap validation for L3 ranges: all L3 subnets share one 
host routing table and one fabric, so an overlap is an address conflict. The 
IPv6 vlan check was already zone-wide.
   
   #### ConfigDrive
   - Network data is always generated for a direct routed NIC; the historical 
gate (Dhcp or Dns supported) held while ConfigDrive supplemented a VR but would 
leave these NICs with no addressing at all. Route generation itself is 
unchanged: cloud-init detects an IPv4 gateway inside 169.254.0.0/16 and sets 
on-link on the rendered route by itself.
   
   #### KVM agent
   - One uplink-less bridge per network, brdr-<network id>, created and removed 
by the new modifybrdr.sh (flock'd, idempotent, refuses to remove a bridge still 
in use). The bridge carries the gateway addresses, forwarding and strict 
rp_filter; separate bridges make isolation between networks topological rather 
than a filtering concern.
   - BridgeVifDriver plugs direct routed NICs into their brdr bridge and runs 
the existing modifymacip.sh hook per NIC to install the static neighbour entry 
and host route, regardless of the host-wide EVPN property, whose meaning is 
unchanged.
   
   The design document, including the decision log and the verification notes 
behind each choice, is added under docs/design/.
   
   ### Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [x] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   - [ ] Build/CI
   - [ ] Test (unit or integration test code)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Feature/Enhancement Scale
   
   - [x] Major
   - [ ] Minor
   
   #### Bug Severity
   
   - [ ] BLOCKER
   - [ ] Critical
   - [ ] Major
   - [x] Minor
   - [ ] Trivial
   
   ### Screenshots (if appropriate):
   
   ### How Has This Been Tested?
   
   Testing is still ongoing on real hardware and this PR currently (July 2026) 
exists to gain initial feedback.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to