[openstack-dev] [ironic] FFE - Requesting FFE for Routed Networks support.

Dmitry Tantsur dtantsur at redhat.com
Wed Jan 17 15:05:15 UTC 2018


Hi!

I'm essentially +1 on granting this FFE, as it's a low-risk work for a great 
feature. See one comment inline.

On 01/17/2018 10:54 AM, Harald Jensås wrote:
> Requesting FFE for Routed Network support in networking-baremetal.
> -------------------------------------------------------------------
> 
> 
> # Pros
> ------
> With the patches up for review[7] we have a working ml2 agent;
> __depends on neutron fix__; and mechanism driver combination that
> enables support to bind ports on neutron routed networks.
> 
> Specifically we report the bridge_mappings data to neutron, which
> enable the _find_candidate_subnets() method in neutron ipam[1] to
> succeed in finding a candidate subnet available to the ironic node when
> ports on routed segments are bound.
> 
> This functionality will allow users to take advantage of the
> functionality added in DHCP Agent[2] which enables the DHCP agent to
> service other subnets on the network via DHCP relay. For Ironic this
> means we can support deploying nodes on a remote L3 network, e.g
> different datacenter or different rack/rack-row.
> 
> 
> 
> # Cons
> ------
> Integration with placement does not currently work.
> 
> Neutron uses Nova host-aggregates in combination with Placement.
> Specifically hosts are added to a host-aggregate for segments based on
> SEGMENT_HOST_MAPPING. Ironic nodes cannot currently be added to host-
> aggregates in Nova. Because of this the following will appear in the
> neutron logs when ironic-neutron agent is started:
>     RESP BODY: {"itemNotFound": {"message": "Compute host <ironic-node-
> id> could not be found.", "code": 404}}
> 
> Also the placement api cannot be used to find good candidate ironic
> nodes with a baremetal port on the correct segment. This will have to be worked around by the operator via capabilities and flavor properties or manual additions to resource providers in placement.
> 
> Depending on the direction of other projects, neutron and nova, the way
> placement will finally work is not certain.
> 
> Either the nova work [3] and [4], or a neutron change to use placement
> only or a fallback to placement in neutron would be possible. In either
> case there should be no need to change the networking-baremetal agent
> or mechanism driver.
> 
> 
> # Risks
> -------
> Unless this bug[5] is fixed we might break the current baremetal
> mechanism driver functionality. I have proposed a patch[6] to neutron
> that fix the issue. In case no fix lands for this neutron bug soon we
> should probably push these changes to Rocky.

Let's add Depends-On to the first patch in the chain to make sure your patches 
don't merge until the fix is merged.

> 
> 
> # Core reviewers
> ----------------
> Julia Kreger, Sam Betts
> 
> 
> 
> 
> [1] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/ip
> am_backend_mixin.py#n697
> [2] https://review.openstack.org/#/c/468744/
> [3] https://review.openstack.org/#/c/421009/
> [4] https://review.openstack.org/#/c/421011/
> [5] https://bugs.launchpad.net/neutron/+bug/1743579
> [6] https://review.openstack.org/#/c/534449/
> [7] https://review.openstack.org/#/q/project:openstack/networking-barem
> etal
> 
> 




More information about the OpenStack-dev mailing list