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 <d...@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.b...@cern.ch
<mailto:tim.b...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
