I put the script up at https://gist.github.com/sorrison/99c8e87295756e0ed787
The cron job that runs is like: #!/bin/bash BASEDIR=/tmp /usr/bin/mysql --defaults-group-suffix=-prod-keystone -B -e 'select target_id, actor_id from assignment inner join project on target_id = project.id inner join user on user.id = actor_id order by target_id, actor_id;' | tail -n+2 > $BASEDIR/keystone_project_users.txt scp $BASEDIR/keystone_project_users.txt root@nova-controller:. ssh root@nova-controller nova-manage shell script sync_quotas_main.py It’s not pretty but it works….. Sam > On 21 Mar 2015, at 12:35 am, Kris G. Lindgren <[email protected]> wrote: > > Can you post of you cronjob/script that you use to correct the quotas? > ____________________________________________ > > Kris Lindgren > Senior Linux Systems Engineer > GoDaddy, LLC. > > > > On 3/20/15, 4:18 AM, "Sam Morrison" <[email protected]> wrote: > >> We¹ve had the following for a year or so but doesn¹t help much, we still >> see it occurring every 10 mins or so. >> >> max_age = 10 >> until_refresh = 5 >> reservation_expire=600 >> >> We have a cron job that runs every 10 mins that figures out what projects >> are out of sync and corrects them. >> We¹ve always been scared of setting these to zero but we probably should. >> >> Sam >> >> >>> On 15 Mar 2015, at 2:53 pm, Mike Dorman <[email protected]> wrote: >>> >>> Yeah the default is just Œ0¹ for both, which disables the refresh. >>> >>> >>> >>> The one downside is that it may not be 100% transparent to the user. >>> If >>> the quota is already (incorrectly) too high, and exceeding the quota >>> limit, the reservation that triggers the refresh will still fail. I.e. >>> the reservation is attempted based on the quota usage values _before_ >>> the >>> refresh. But then after that the quota should be fixed and it will >>> work >>> again on the next reservation. >>> >>> But my thinking is that most quota issues happen slowly over time. If >>> we >>> are correcting them often and automatically, they hopefully never get >>> to >>> the point where they¹re bad enough to manifest reservation errors to >>> the >>> user. >>> >>> I don¹t have any information re: db load. I assume it regenerates >>> based >>> on what¹s in the instances or reservations table. I imagine the load >>> for >>> doing a single refresh is probably comparable to doing a Œnova list¹. >>> >>> Mike >>> >>> >>> >>> On 3/14/15, 2:27 PM, "Tim Bell" <[email protected]> wrote: >>> >>>> Interesting... what are the defaults ? >>>> >>>> Assuming no massive DB load, getting synced within a day would seem >>>> reasonable. Is the default no max age ? >>>> >>>> Tim >>>> >>>>> -----Original Message----- >>>>> From: Jesse Keating [mailto:[email protected]] >>>>> Sent: 14 March 2015 16:59 >>>>> To: [email protected] >>>>> Subject: Re: [Openstack-operators] max_age and until_refresh for >>>>> fixing >>>>> Nova >>>>> quotas >>>>> >>>>> On 3/14/15 8:11 AM, Mike Dorman wrote: >>>>>> I did short write-up here http://t.co/Q5X1hTgJG1 if you are >>>>>> interested >>>>>> in the details. >>>>>> >>>>> >>>>> Thanks for sharing Matt! That's an excellent write up. >>>>> >>>>> -- >>>>> -jlk >>>>> >>>>> _______________________________________________ >>>>> OpenStack-operators mailing list >>>>> [email protected] >>>>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>>> >>>> _______________________________________________ >>>> OpenStack-operators mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> _______________________________________________ >>> OpenStack-operators mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> _______________________________________________ >> OpenStack-operators mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
