[openstack-dev] [Neutron][ML2][Routed Networks]

Hong Hui Xiao xiaohhui at cn.ibm.com
Thu May 19 03:48:18 UTC 2016


Thanks for the clarification. If we are going to have dhcp service in 
every segment separately, then I think the current behavior is reasonable. 
The remaining segments can use dhcp by the dhcp ports in their own 
segments.

HongHui Xiao(肖宏辉)




From:   Carl Baldwin <carl at ecbaldwin.net>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date:   05/19/2016 05:34
Subject:        Re: [openstack-dev] [Neutron][ML2][Routed Networks]



On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao <xiaohhui at cn.ibm.com> 
wrote:
> I update [1] to auto delete dhcp port if there is no other ports. But
> after the dhcp port is deleted, the dhcp service is not usable. I can

I think this is what I expect.

> resume the dhcp service by adding another subnet, but I don't think it 
is
> a good way. Do we need to consider bind dhcp port to another segment 
when
> deleting the existing one?

Where would you bind the port?  DHCP requires L2 connectivity to the
segment which it serves.  But, you deleted the segment.  So, it makes
sense that it wouldn't work.

Brandon is working on DHCP scheduling which should take care of this.
DHCP should be scheduled to all of the segments with DHCP enabled
subnets.  It should have a port for each of these segments.  So, if a
segment (and its ports) are deleted, I think the right thing to do is
to make sure that DHCP scheduling removes DHCP from that segment.  I
would expect this to happen automatically when the subnet is deleted.
We should check with Brandon to make sure this works (or will work
when his work merges).

Carl

> [1] https://review.openstack.org/#/c/317358

__________________________________________________________________________
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






More information about the OpenStack-dev mailing list