/me +1 too.
--ruby
On 2018-01-17, 10:05 AM, "Dmitry Tantsur" <dtant...@redhat.com> wrote:
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
__________________________________________________________________________
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
