[openstack-dev] [oslo.db] [CC neutron] CIDR overlap functionality and constraints

Mike Bayer mbayer at redhat.com
Fri Jul 22 14:00:26 UTC 2016



On 07/21/2016 02:43 PM, Carl Baldwin wrote:
>
> None of these operations are expected to be very contentious and
> performance hasn't really been a concern yet. If it were a big concern,
> I'd be very interested in the GiST index solution because, as I
> understand it, detecting overlap without that capability requires a
> linear search through the existing records. But, GiST index capability
> isn't ubiquitous which makes it difficult to get excited about for
> practical purposes. I do have an academic interest in it. Computational
> geometry used to be a hobby of mine when I worked on tools for physical
> design of microchips. I've been telling people for years that I thought
> it'd be cool if databases had some facility for indexing potentially
> overlapping ranges in one or more dimensions. This looks like some
> pretty cool stuff.
>
> Can you think of any other operations in Neutron -- or elsewhere in
> OpenStack -- which will benefit from these new functions? I'll be
> honest. Without some compelling benefit, it may be very difficult to
> swallow the pill of dealing with special case code in each kind of DB
> for this capability. But, if it is abstracted sufficiently by oslo db,
> it might be worth looking at down the road. The changes to adopt such
> functionality shouldn't be too difficult.

Well let me reiterate the idea, which is that:

1. we add features to oslo.db so that the use of a custom stored 
function is not a big deal

2. we add features to oslo.db that are based on using triggers, special 
constraints, or Gist indexes, so that the use of a database constraint 
that needs this kind of thing is not a big deal

3. the first proof of concept for this, is a CIDR function / trigger for 
this one reported issue in Neutron.

Now the question is, "can I think of any operation in openstack, besides 
this one, that would benefit from a custom stored function or a 
specialized constraint".   The answer for me is "not specifically but i 
bet if I started looking, I would".  Anytime there's an application 
loading some rows of data out of a table, doing some calculations on it, 
then dealing with a subset of those rows as a result, is a candidate for 
#1 (in fact I have some vague recollection of seeing some patch in 
Neutron that had this issue, it was the reason that compare-and-swap 
could not be used).   Anytime an application is trying to insert rows 
into a table which should be rejected based on some criteria beyond 
"unique key", that's a candidate for #2 - perhaps the plethora of 
UUID-based recipes throughout openstack in some cases could be better 
stated by more data-driven constraints.

If we were to decide that the Neutron issue right here doesn't need any 
changes, then I would be fine abandoning this initiative for now.  But 
as it stands, there seems to be a need to either do this change, *or* 
add a new UUID column to the subnets table, and basically I'm hoping to 
start steering the boat away from the island of 
add-a-new-column-everytime-theres-a-concurrency-problem.







More information about the OpenStack-dev mailing list