On Wed, 2018-01-17 at 10:54 +0100, 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.
>
>
> # 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/
>
ooops .. got the wrong urls in the first mail.
[3] https://review.openstack.org/#/c/526753/
[4] https://review.openstack.org/#/c/529135/
> [5] https://bugs.launchpad.net/neutron/+bug/1743579
> [6] https://review.openstack.org/#/c/534449/
> [7] https://review.openstack.org/#/q/project:openstack/networking-bar
> em
> etal
>
>
--
|Harald Jensås
|hjen...@redhat.com | www.redhat.com
|+46 (0)701 91 23 17 | hjensas:irc
__________________________________________________________________________
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
