Open Stack

On Wed, 2018-01-17 at 16:05 +0100, Dmitry Tantsur 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.
> 

The fix for the neutron issue was approved and is now merged.
https://review.openstack.org/#/c/534449/



> > 
> > 
> > # Core reviewers
> > ----------------
> > Julia Kreger, Sam Betts
> > 
> > 
> > 
> > 
> > [1] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/d
> > b/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-b
> > arem
> > etal
> > 
> > 
> 
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
|Harald Jensås        
|hjensas at redhat.com   |  www.redhat.com
|+46 (0)701 91 23 17  |  hjensas:irc