[adoption_osp_deploy] Add DCN adoption support #3570
Conversation
Adds support for deploying DCN with local storage (which is essentially multi-stack plus spine & leaf networking) to the adoption_osp_deploy role. Signed-off-by: Oliver Walsh <owalsh@redhat.com>
Modify os_net_config_overcloud.yml.j2 template to render per-network
routes from stack configuration instead of hardcoded empty routes.
Problem:
- Template had hardcoded "routes: []" for all VLAN networks (line 40)
- DCN compute nodes need routes to reach central site services
- Routes defined in data-plane-adoption's network_data.yaml.j2 were
being ignored because ci-framework pre-generates os-net-config files
before TripleO Heat deployment runs
Solution:
- Check if _stack.network_routes is defined and contains routes for
the current network
- If routes exist, render them with ip_netmask and next_hop
- Otherwise, fall back to empty routes array
This enables DCN scenarios to configure cross-site routes via the
network_routes field in stack definitions (dcn_nostorage.yaml).
Example usage in stack config:
network_routes:
internalapidcn1:
- ip_netmask: 172.17.0.0/24
next_hop: 172.17.10.1
Related: Requires corresponding data-plane-adoption change to add
network_routes to dcn1/dcn2 stack definitions.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: John Fulton <fulton@redhat.com>
Add edpm_dcn1_routes and edpm_dcn2_routes variables to adoption_vars.yaml template. These variables extract network routes defined in the TripleO scenario file (dcn_nostorage.yaml) and make them available for EDPM ansible configuration. Routes are extracted from stack.network_routes for dcn1 and dcn2 stacks, with each route containing destination (ip_netmask) and nexthop fields. This enables proper inter-site connectivity in DCN deployments where compute nodes in edge sites need routes to reach control plane services in the central site. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: John Fulton <fulton@redhat.com>
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/164182cfd2c244d8a1cf9d4c183185cc ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 50m 59s |
| # DCN network routes extracted from TripleO scenario | ||
| {% set _dcn1_stack = cifmw_adoption_osp_deploy_scenario.stacks | selectattr('stackname', 'equalto', 'dcn1') | first | default({}) %} | ||
| {% if _dcn1_stack.network_routes is defined %} | ||
| edpm_dcn1_routes: |
There was a problem hiding this comment.
[related to first commit]
(blocking) suggestion: I see here a good candidate for a refactor:
{% for site in ['dcn1', 'dcn2'] %}
{% set _stack = cifmw_adoption_osp_deploy_scenario.stacks | selectattr('stackname', 'equalto', site) | first | default({}) %}
{% if _stack.network_routes is defined %}
edpm_{{ site }}_routes:
{% for subnet_name, routes in _stack.network_routes.items() %}
{{ subnet_name }}:
{% for route in routes %}
- destination: {{ route.ip_netmask }}
nexthop: {{ route.next_hop }}
{% endfor %}
{% endfor %}
{% endif %}
{% endfor %}
|
Where's dcn_nostorage file? |
| addresses: | ||
| - ip_netmask: {{ net[ip_version|default('ip_v4')] }}/{{ net[prefix_length_version|default('prefix_length_v4')] }} | ||
| {% if _stack.network_routes is defined and network_name in _stack.network_routes %} | ||
| routes: |
There was a problem hiding this comment.
(non-blocking) concern: As this is not touched by this PR, I'm marking this comment as non-blocking.
I was checking the output of the routes, and in this PR it seems correct.
But above, at L17, the "routes:" are inside the "{%- for route in _stack.routes %}" which might end up by having two differente routes section like:
routes:
- ip_netmask: first
routes:
- ip_netmask: second
I see here that "routes:" is properly set outside the for loop.
| - osp_trunk | ||
| # Let's remove the default computes, since we want to adopt the | ||
| # OSP ones | ||
| compute: |
There was a problem hiding this comment.
(non-blocking) question: is this something required to be there to avoid a runtime error? Should we create a task for solving this?
3 participants
Adds support for deploying DCN with local storage (which is essentially
multi-stack plus spine & leaf networking) to the adoption_osp_deploy role.