Comment 10 for bug 1668145

Revision history for this message
Brian Haley (brian-haley) wrote :

Just some notes from a discussion on #openstack-neutron

<hjensas> kevinbenton: There is indeed multiple physnets. But, the single node running neutron services is not connected to more than 1 physnet. The nodes in the other physnets are baremetal machines, under Openstack Ironic.
<kevinbenton> hjensas: that's fine, but when the ports are created for those ironic nodes, they should get associated with subnets on different segments
<hjensas> kevinbenton: We need the single machine only connected to one physnet to provide DHCP for Ironic nodes on multiple physnets. The datacenter have the routing infrastructure, and dhcp-relay agents on the routers/ToR switches.
<hjensas> kevinbenton: but I cannot create multiple segments without multiple physical-networks on the neutron node.
<kevinbenton> hjensas: yes you can, just specify different physnets
<kevinbenton> hjensas: that doesn't mean those physnets are on the neutron node
<hjensas> kevinbenton: ah, so I don't need a bridge_mapping with the physnet?
<hjensas> kevinbenton: I can create --physical-network foo ...
<kevinbenton> hjensas: the bridge_mapping is just to tell which physnets a given node can access
<kevinbenton> hjensas: in the neutron server config for [ml2_type_flat], you may need to add physnets there if it's not set to '*'
<hjensas> kevinbenton: yes, I see. I can create multiple segments.
<kevinbenton> hjensas: now the problem you may run into is getting the port actually bound to the correct segment
<kevinbenton> hjensas: IIRC ironic ports are actually just left UNBOUND, right?
<kevinbenton> hjensas: or do they have a mechanism driver loaded?
<hjensas> kevinbenton: well, the next problem is that I get 1 DHCP namespace, with dhcp opts for 1 subnet.
<kevinbenton> hjensas: well how many subnets do you have on the network?
<hjensas> kevinbenton: 3
<kevinbenton> hjensas: and creating segments eliminated the other two?
<kevinbenton> (in DHCP namespace)
<hjensas> kevinbenton: I have 1 network, 3 segments with 1 subnet in each segment. - I get 1 DHCP namespace with 1 port in segment1 - subnet0, and opts for subnet0 only.
<kevinbenton> hjensas: and dhcp is enabled on other 2, right?
<kevinbenton> hjensas: oh, i see the issue
<kevinbenton> hjensas: it looks like we have the assumption built into dhcp scheduler that it won't be able to service remote subnets
<kevinbenton> hjensas: i don't think the dhcp relay use case was considered
<hjensas> kevinbenton: http://paste.openstack.org/show/607919/
<hjensas> kevinbenton: but, I do have bridge_mappings for 2 segments. So we should see two namespaces? Or atleast opts for two subnets?
<kevinbenton> hjensas: we should just see opts inside the one namespace
<kevinbenton> hjensas: but that's being explicitly prevented right now
<kevinbenton> hjensas: because of some logic that thinks there is no point in the dhcp agent trying to serve a network it's not attached to
<kevinbenton> hjensas: https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/dhcp_rpc.py#L152-L155
<kevinbenton> hjensas: let me think about this for a bit, we may just want to remove that logic completely to consider dhcp relay
<hjensas> kevinbenton: I created this earlier today: https://blueprints.launchpad.net/neutron/+spec/dhcp-remote-subnets-with-relay
<hjensas> kevinbenton: it is an idea for relay.
<kevinbenton> hjensas: so that wouldn't be needed if this use case is fixed up and I remove that logic above, right?
<kevinbenton> hjensas: i.e. the dhcp agent will serve requests for any subnets on the network
<hjensas> kevinbenton: The DHCP agent will by default create a port and the namespace get an IP address on each subnet. If the subnet is not local, it wont send responses back via the gateway.
<hjensas> kevinbenton: sorry, let me rephrase. The DHCP agent think it is local to all subnets, since it has IP in each subnet, and wont send the response back via the gateway.
<kevinbenton> hjensas: oh, right, forgot about the local IP
<kevinbenton> hjensas: well we can still ensure the agent doesn't request a local IP from a segment it's not attached to
<kevinbenton> hjensas: just as long as it sets up the reservations
<kevinbenton> hjensas: would that work?
<kevinbenton> hjensas: so agent sets up all reservations for a network regardless of segment
<kevinbenton> hjensas: and then only requests IPs on the segment subnets it's attached to
<hjensas> kevinbenton: But IP only on local segments. that should work.
<kevinbenton> hjensas: ok, let me think about it a bit more, but I think that should be pretty easy to do
<kevinbenton> hjensas: and would reduce code for us
<hjensas> kevinbenton: sounds good. Let me know if you need anything, help testing etc.
<kevinbenton> hjensas: will do

Action items:

1. haleyb updates https://review.openstack.org/#/c/438171/ to not include on-link routes if subnets on network have a segment_id

2. haleyb changes port update logic requesting additional IPs

3. kevinbenton works on pulling out the server-side filtering of networks - https://review.openstack.org/#/c/459861/