On 03/16/2016 09:34 AM, gordon chung wrote:
>
>
> On 16/03/2016 7:10 AM, Attila Fazekas wrote:
>>
>> NO : For any kind of extra quota service.
>>
>> In other places I saw other reasons for a quota service or similar,
>> the actual cost of this approach is higher than most people would think so
>> NO.
>>
>>
>> Maybe Library,
>> But I do not want to see for example the bad pattern used in nova to spread
>> everywhere.
>>
>> The quota usage handling MUST happen in the same DB transaction as the
>> resource record (volume, server..) create/update/delete .
>>
>> There is no need for.:
>> - reservation-expirer services or periodic tasks ..
>> - there is no need for quota usage correcter shell scripts or whatever
>> - multiple commits
>>
>>
>> We have a transaction capable DB, to help us,
>> not using it would be lame.
>>
>>
>> [2] http://lists.openstack.org/pipermail/openstack-dev/2015-April/061338.html
>
> i personally like this reasoning. i also wonder how upgrades are
> affected because of this decoupling proposal -- does this mean the
> upgrades of all services would be linked (potentially)?
Not if this was a library that defined tables inside the projects in
question, not in some 3rd db place.
This has to live inside all the upgrade constraints we currently have
(like online data migration in the Nova case), otherwise it's a non starter.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
