Open Stack

On 03/16/2016 10:04 AM, Davanum Srinivas wrote:
> To complete the context:
> https://review.openstack.org/#/c/132127/
> https://etherpad.openstack.org/p/kilo-oslo-common-quota-library (from
> https://wiki.openstack.org/wiki/Design_Summit/Kilo/Etherpads)
>
> -- Dims
>
> On Wed, Mar 16, 2016 at 9:53 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Sean Dague's message of 2016-03-16 06:09:47 -0400:
>>> On 03/16/2016 05:46 AM, Duncan Thomas wrote:
>>>> On 16 March 2016 at 09:15, Tim Bell <Tim.Bell at cern.ch
>>>> <mailto:Tim.Bell at cern.ch>> wrote:
>>>>
>>>>      Then, there were major reservations from the PTLs at the impacts in
>>>>      terms of
>>>>      latency, ability to reconcile and loss of control (transactions are
>>>>      difficult, transactions
>>>>      across services more so).
>>>>
>>>>
>>>> Not just PTLs :-)
>>>>
>>>>
>>>>      <snip>
>>>>      I would favor a library, at least initially. If we cannot agree on a
>>>>      library, it
>>>>      is unlikely that we can get a service adopted (even if it is desirable).
>>>>
>>>>      A library (along the lines of 1 or 2 above) would allow consistent
>>>>      implementation
>>>>      of nested quotas and user quotas. Nested quotas is currently only
>>>>      implemented
>>>>      in Cinder and user quota implementations vary between projects which is
>>>>      confusing.
>>>>
>>>>
>>>> It is worth noting that the cinder implementation has been found rather
>>>> lacking in correctness, atomicity requirements and testing - I wouldn't
>>>> suggest taking it as anything other than a PoC to be honest. Certainly
>>>> it should not be cargo-culted into another project in its present state.
>>> I think a library approach should probably start from scratch, with
>>> lessons learned from Cinder, but not really copied code, for just that
>>> reason.
>>>
>>> This is hard code to get right, which is why it's various degrees of
>>> wrong in every project in OpenStack.
>>>
>>> A common library with it's own db tables and migration train is the only
>>> way I can imagine this every getting accomplished given the atomicity
>>> and two phase commit constraints of getting quota on long lived, async
>>> created resources, with sub resources that also have quota. Definitely
>>> think that's the nearest term path to victory.
>> When we talked about this in Paris (I think, all these hotel basements
>> are starting to look the same), the main issue with the library was how
>> to tie in db table management with the existing tables owned by the app.
>> It's not impossible to solve, but we need some thought to happen
>> around the tools for that. Maybe some of the lessons of incremental
>> on-demand table updates in nova will help there.
>>
>> Doug

Assuming we are working with SQL Alchemy and Migrations, I would suggest 
that the quota table be put into its own table namespace, separate from 
the rest of the application.  We did this for a while with Keystone 
extensions, in order to allow them to avoid revision number conflicts as 
reviews came in.

The Migrations table looks like this:
desc migrate_version;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| repository_id   | varchar(250) | NO   | PRI | NULL    |       |
| repository_path | text         | YES  |     | NULL    |       |
| version         | int(11)      | YES  |     | NULL    |       |
+-----------------+--------------+------+-----+---------+-------+

And you can see there is a repository_path variable that lets that vary.

Keystone has only:


  select * from migrate_version;
+---------------+-------------------------------------------------------------------+---------+
| repository_id | 
repository_path                                                   | 
version |
+---------------+-------------------------------------------------------------------+---------+
| keystone      | 
/usr/lib/python2.7/site-packages/keystone/common/sql/migrate_repo |      
94 |
+---------------+-------------------------------------------------------------------+---------+


Note that there is one of these tables per Service database, so even if 
Keystoen and Nova share a mysql instance, they have their own copy of 
this table.







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