<div dir="ltr">><span style="font-size:12.8px">I kind of think it makes sense to require evacuating a segment of its </span><span style="font-size:12.8px">ports before deleting it.</span><div><br></div><div>Ah, I left out an important assumption I was making. We also need to auto delete the DHCP port as the segment is deleted. I was thinking this will be basically be like the delete_network case where we will auto remove the network owned ports.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 17, 2016 at 12:29 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, May 17, 2016 at 10:56 AM, Kevin Benton <kevin@benton.pub> wrote:<br>
>>a) Deleting network's last segment will be prevented. Every network should<br>
>> have at least one segment to let the port to bind.<br>
><br>
> This seems a bit arbitrary to me. If a segment is limited to a small part of<br>
> the datacenter, it being able to bind for one section of the datacenter and<br>
> not the rest is not much different than being able to bind from no sections.<br>
> Just allow it to be deleted because we need to have logic to deal with the<br>
> unbindable port case anyway. Especially since it's a racy check that is hard<br>
> to get correct for little gain.<br>
<br>
</span>I agree with Kevin here.<br>
<span class=""><br>
>>b) Deleting the segment that has been associated with subnet will be<br>
>> prevented.<br>
><br>
> +1<br>
<br>
</span>++<br>
<span class=""><br>
>>c) Deleting the segment that has been bound to port will be prevented.<br>
><br>
> +1.<br>
<br>
</span>++<br>
<span class=""><br>
>>d) Based on c), we need to query ml2_port_binding_levels, I think<br>
>> neutron.plugins.ml2.models.PortBindingLevel should be moved out of ml2. This<br>
>> is also because port and segment are both neutron server resources, no need<br>
>> to keep PortBindingLevel at ml2.<br>
><br>
> There are things in this model that make sense only to ML2 (level and<br>
> driver), especially since ML2 allows a single port_id to appear multiple<br>
> times in the table (primary key is port_id + level).  To achieve your goals<br>
> in 'C' above, just emit a BEFORE_DELETE event in the callback registry for<br>
> segments. Then ML2 can query this table with a registered callback and other<br>
> plugins can register a callback to prevent this however they want.<br>
<br>
</span>Sounds reasonable.<br>
<span class=""><br>
> However, be sure to ignore the DHCP port when preventing segment deletion<br>
> otherwise having DHCP enabled will make it difficult to get rid of a<br>
> segment.<br>
<br>
</span>They will be left somewhat defunct, won't they?  I think a foreign key<br>
constraint would be violated if you tried to delete a segment with<br>
even a DHCP port on it.<br>
<br>
  port <- ipallocations (FK) -> subnets (FK) -> networksegments<br>
<br>
I guess there is no foreign key constraint holding the ipallocations<br>
to the port.  So, the ipallocations could be deleted.  But, that is<br>
effectively stripping an existing port of its IP addresses which would<br>
be weird.<br>
<br>
I kind of think it makes sense to require evacuating a segment of its<br>
ports before deleting it.<br>
<span class=""><br>
>>e) Is it possible to update a segment(physical_network, segmentation_id, or<br>
>> even network_type), when the segment is being used?<br>
><br>
> I would defer this for future work and not allow it for now. If the segment<br>
> details change, we need to ask the drivers responsible for every bound port<br>
> to make they can support it under the new conditions. It will be quite a bit<br>
> of logic to deal with that I don't think we need to support up front.<br>
<br>
</span>++ Simplify!  We don't have a use case for this now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Carl<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>