Can we tag this patch for backporting to Havana stable ? We're starting work for the CERN upgrade and this looks like a very useful patch to be part of the standard Havana offering.
Tim > -----Original Message----- > From: Jonathan Proulx [mailto:j...@jonproulx.com] > Sent: 12 January 2014 18:32 > To: Morgan Fainberg > Cc: openstack@lists.openstack.org > Subject: Re: [Openstack] [Keystone] performance issues after havana upgrade > > puzzling side effect? > > I just made a small change to neutron.conf (adjusted a default quota) and > restarted neutron-server, now neutron (but not other services) > is > spweing: > > Invalid user token - rejecting request > > (quite possibly only from dashboard requests CLI seems to work). I've tried > restarting keystone (in both wsgi and eventlet modes), > restarting neutron-server w/ reverted config and flushing/restarting > memcached in various combinations. > > I don't really see how restarting neutron-server could confuse token > validation... > > > On Sun, Jan 12, 2014 at 10:38 AM, Morgan Fainberg <mor...@metacloud.com> > wrote: > > Thanks for confirming this! It also validates my new logic going into > > icehouse (I might have had some ulterior motives here, or not so > > ulterior as the case may be). I'll make sure we resolve the test > > issues (unrelated to the patch) and get it into the Havana tree so you > > don't need to maintain it outside of the releases. > > > > Cheers, > > Morgan > > > > Sent from my tablet-like-device > > > >> On Jan 11, 2014, at 11:01 PM, Jonathan Proulx <j...@jonproulx.com> wrote: > >> > >>> On Sat, Jan 11, 2014 at 10:57 PM, Morgan Fainberg <m...@metacloud.com> > >>> wrote: > >>> Sounds good! Just remember that prior to the fix I posted there, > >>> for each token in the user's index, it incurred a round-trip to > >>> memcached to validate the token wasn't expired. This change makes > >>> it so that there are significantly less trips from keystone to memcached. > >>> > >>> If this doesn't 100% solve the issue, we should start digging > >>> further into what is going on, but I am confident this will (at the > >>> very least) help a reasonable amount. > >> > >> You sir are a miracle worker, my hat is off! > >> > >> The responsiveness of everything is better than it's ever been, my > >> users will think this is the best feature the upgrade. > >> > >> For example earlier today I managed to launch 10 VMs in parallel, > >> eventually, I'd guess on the order of 5-10min. One of my usual > >> acceptance tests is being able to launch 100 VMs in that time. Just > >> now Iaunched 100 in <2min from request until they'd all been > >> provisioned and were booting. Now there's too many moving pieces and > >> too few experimental samples to make any publishable claims, but your > >> patch is the only thing that changed. > >> > >> Thanks, > >> -Jon > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
