JamesBhattarai/3cloud-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(xcloudify): add ovs_bridge support for network management

Browse Source 
Add ovs_bridge parameter to xcloudify_network module and client utilities
to enable OVS bridge configuration for VXLAN networks. Includes validation,
documentation, and example updates.
This commit is contained in:
coryHawkvelt
2026-01-27 10:44:02 +10:30
parent a6eb0eb4b7
commit 433bec4556
6 changed files with 49 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ansible/examples/webserver-with-content-generator.yml
+2 -1
View File
@@ -25,6 +25,7 @@
ipv4_cidr: "10.2.0.0/24"
ipv4_gateway: "10.2.0.1"
ipv4_dns_servers: "8.8.8.8,8.8.4.4"
# ovs_bridge: br-int
description: "Web server and content generator network"
volumes:
@@ -87,4 +88,4 @@
debug:
msg: |
Note: The 'pod_name' parameter creates/attaches containers to a pod named 'my-custom-pod', enabling multi-container deployments on the same host with shared networking and lifecycle.
{% endfor %}
{% endfor %}
ansible/roles/xcloudify_infrastructure/README.md
+7 -1
View File
@@ -66,6 +66,7 @@ xcloudify_infrastructure:
ipv4_cidr: "10.1.0.0/24"
ipv4_gateway: "10.1.0.1"
ipv4_dns_servers: "8.8.8.8,8.8.4.4"
# ovs_bridge: br-int # Optional: OVS bridge name; required for OVS-backed VXLAN networks unless XCF_DEFAULT_OVS_BRIDGE is set on the API server
description: "Web tier network"
volumes:
@@ -400,9 +401,14 @@ networks:
ipv4_cidr: "10.1.0.0/24" # Optional: IPv4 CIDR block
ipv4_gateway: "10.1.0.1" # Optional: IPv4 gateway
ipv4_dns_servers: "8.8.8.8" # Optional: DNS servers (comma-separated)
ovs_bridge: "br-int" # Optional: OVS bridge. If omitted, API uses env XCF_DEFAULT_OVS_BRIDGE if set; otherwise workers may reject network port ops
description: "Network desc" # Optional: Description
```
Note on OVS bridges
- The ovs_bridge field specifies the OVS integration bridge that VXLAN ports should attach to on worker hosts (e.g., br-int).
- If not provided per-network, the API will check the environment variable XCF_DEFAULT_OVS_BRIDGE. When neither is set, the server omits ovs_bridge from payloads and workers may reject port operations for OVS-backed networks.
### Volumes
```yaml
@@ -489,4 +495,4 @@ MIT
## Author Information
xCloudify Team - Infrastructure as Code Solutions
xCloudify Team - Infrastructure as Code Solutions
ansible/roles/xcloudify_infrastructure/library/xcloudify_network.py
+9 -1
View File
@@ -56,6 +56,10 @@ options:
description: DNS servers (comma-separated)
required: false
type: str
ovs_bridge:
description: OVS bridge to attach VXLAN port on worker hosts. If omitted, API will use XCF_DEFAULT_OVS_BRIDGE env var if set; otherwise workers may reject operations.
required: false
type: str
description:
description: Network description
required: false
@@ -184,6 +188,10 @@ def validate_network_spec(network_spec):
ipaddress.ip_address(network_spec['ipv4_gateway'])
except ValueError:
errors.append(f"Invalid IPv4 gateway: {network_spec['ipv4_gateway']}")
# Optional ovs_bridge must be a string when provided
if 'ovs_bridge' in network_spec and network_spec['ovs_bridge'] is not None and not isinstance(network_spec['ovs_bridge'], str):
errors.append("ovs_bridge must be a string when provided")
return errors
@@ -357,4 +365,4 @@ def main():
if __name__ == '__main__':
main()
main()
ansible/roles/xcloudify_infrastructure/module_utils/xcloudify_client.py
+6 -3
View File
@@ -220,14 +220,17 @@ class XCloudifyClient:
'ipv4_dns_servers': network_spec.get('ipv4_dns_servers'),
'description': network_spec.get('description', f"Network {network_spec['name']}")
}
# Optional bridge passthrough
if 'ovs_bridge' in network_spec and network_spec.get('ovs_bridge') is not None:
network_data['ovs_bridge'] = network_spec.get('ovs_bridge')
result = self._make_request('POST', 'networks', network_data)
return result, True # created
else:
# Check if update needed
needs_update = False
update_data = {}
for field in ['vni', 'ipv4_cidr', 'ipv4_gateway', 'ipv4_dns_servers', 'description']:
for field in ['vni', 'ipv4_cidr', 'ipv4_gateway', 'ipv4_dns_servers', 'description', 'ovs_bridge']:
if field in network_spec and existing.get(field) != network_spec[field]:
needs_update = True
update_data[field] = network_spec[field]
@@ -776,4 +779,4 @@ class XCloudifyClient:
if self._container_needs_recreation(existing_container, spec):
return True
return False
return False
docs/major todo items.md
+23 -20
View File
@@ -335,18 +335,8 @@ Provide a comprehensive architectural design with clear recommendations and trad
WIP - Delete OVS prts when container deletes
ensure ovs mappings get to api
create a container with a non-host network
Does the server send the port name in the payload? If so then the snd-update in advance of the workload creation is required
Should we have the dns_update tasks depend on container creation? Does it need to run before the new container is running or can it be run after? Is it less effiecent to have it run after new pod\container creation cos dnsmasq will need ot be updated and reloaded?
When deleting a containeer, the ports dont seem to be getting deleted frombr-int - FIXED
When deleting a container send_sdn_updates_for_networks doesnt run, even though it looks like it should
@@ -359,21 +349,32 @@ Test buildign a container with cloudflare, internalDNS(Between pods on smae host
assess the depends_on sceham for tasks,if a parent task fails, should we continue? at present we trigger child tasks no matter what.
# IMPORTANT!
When dispatching DNS or SDN updates, dont dispatch to hosts that are offline, elese they'll buildup a load of backlogged tasks that might not make sense to run when they come back, instead during the reconciliation run a DNS update and SDNUpdate for all VDC & Networks on that host - needs review
# Urgent!
Creating a container triggers dns updates where dns updates shoudlnt go
Somethign funky is goig on in the no1 region when 2 hosts go down then come back up a few mins later their workload gets deleted. It should attempt toget moved, fail, then just stay where it is.
When creating an ovs port and moving it into a ns, it might already be there(EG if we are doing a reconcilation) check for this and skip the namespace move if so
launching a container in no1 causes events on macdc
add flags for increased logging of various functions like ENABLE_ENHANCED_LOGGING_DNS, ENABLE_ENHANCED_LOGGING_SDNUPDATES, ENABLE_ENHANCED_LOGGING_WORKLOADPLACEMENT
KLaunching a container doesnt seem to creat port forwardings?
Port forwardings get fucked up on reconciliation
On the worker, when creating a container, if the payload for container creation specifies a network port then dont use the docker bridge. Create the nscontroller with no networking becuase later on we will shove an ovs port into it's namespace, therby enabling networking.
---------------
@@ -426,4 +427,6 @@ You are an expert Hugo documentation builder tasked with creating comprehensive,
- Optimize for users: Fast-loading, mobile-friendly, SEO with meta descriptions.
- Output the complete folder structure with all files generated, ready for `hugo deploy` or static hosting.
The final deliverable is a production-ready, fully functional Hugo site in `user_facing_docs/` containing accurate, code-derived documentation for all user-facing features. Provide the full directory tree and key file contents in your response.
The final deliverable is a production-ready, fully functional Hugo site in `user_facing_docs/` containing accurate, code-derived documentation for all user-facing features. Provide the full directory tree and key file contents in your response.
docs/scripts/launch_single_container.sh
+2 -2
View File
@@ -25,8 +25,8 @@ curl -X POST "http://${SERVER_IP}:5000/api/workloads/containers" \
],
"env": { "PORT": "9090" },
"restart_policy": "always",
"cpu": 40,
"mem_limit": 1024
"cpu": 1,
"mem_limit": 128
}
]
}