Open Stack

On Tue, May 17, 2016 at 10:56 AM, Kevin Benton <kevin at benton.pub> wrote:
>>a) Deleting network's last segment will be prevented. Every network should
>> have at least one segment to let the port to bind.
>
> This seems a bit arbitrary to me. If a segment is limited to a small part of
> the datacenter, it being able to bind for one section of the datacenter and
> not the rest is not much different than being able to bind from no sections.
> Just allow it to be deleted because we need to have logic to deal with the
> unbindable port case anyway. Especially since it's a racy check that is hard
> to get correct for little gain.

I agree with Kevin here.

>>b) Deleting the segment that has been associated with subnet will be
>> prevented.
>
> +1

++

>>c) Deleting the segment that has been bound to port will be prevented.
>
> +1.

++

>>d) Based on c), we need to query ml2_port_binding_levels, I think
>> neutron.plugins.ml2.models.PortBindingLevel should be moved out of ml2. This
>> is also because port and segment are both neutron server resources, no need
>> to keep PortBindingLevel at ml2.
>
> There are things in this model that make sense only to ML2 (level and
> driver), especially since ML2 allows a single port_id to appear multiple
> times in the table (primary key is port_id + level).  To achieve your goals
> in 'C' above, just emit a BEFORE_DELETE event in the callback registry for
> segments. Then ML2 can query this table with a registered callback and other
> plugins can register a callback to prevent this however they want.

Sounds reasonable.

> However, be sure to ignore the DHCP port when preventing segment deletion
> otherwise having DHCP enabled will make it difficult to get rid of a
> segment.

They will be left somewhat defunct, won't they?  I think a foreign key
constraint would be violated if you tried to delete a segment with
even a DHCP port on it.

  port <- ipallocations (FK) -> subnets (FK) -> networksegments

I guess there is no foreign key constraint holding the ipallocations
to the port.  So, the ipallocations could be deleted.  But, that is
effectively stripping an existing port of its IP addresses which would
be weird.

I kind of think it makes sense to require evacuating a segment of its
ports before deleting it.

>>e) Is it possible to update a segment(physical_network, segmentation_id, or
>> even network_type), when the segment is being used?
>
> I would defer this for future work and not allow it for now. If the segment
> details change, we need to ask the drivers responsible for every bound port
> to make they can support it under the new conditions. It will be quite a bit
> of logic to deal with that I don't think we need to support up front.

++ Simplify!  We don't have a use case for this now.

Carl