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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev