Open Stack

Mike Bayer wrote:

> 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.

Hello Mike,

Thanks for your idea, If this feature can be moved to Oslo_db then
that's better because Oslo_db has more people with experience of Database
than Neutron has. Do you have any plan for this in Newton cycle?
If yes would you mind sharing me about your plan?

In case we couldn't move this one in Newton cycle then we should have
an alternative solution which Kevin mentioned as "compare-and-swap".
In next cycle, we will come back your idea. How do you think?


Kevin Benton wrote:

> we can solve this particular bug by doing a compare and swap
> operation on some network scoped value (at the cost of all subnet creates
> on the same network becoming serialized via conflicts and retries).

Hello Kevin,

In my understanding, after your patch set [1] is merged, we can add one
line of code so that the systems will increase the revision_number value
of a network which contain a subnet before adding/deleting the subnet,
Am I right?

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

Thanks and best regards,
NamNH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160728/4a2e32b8/attachment.html>