Open Stack

/me +1 too.

--ruby

On 2018-01-17, 10:05 AM, "Dmitry Tantsur" <dtantsur at 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-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev