<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi Tim,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The change is being proposed directly to stabe/havana.  We have an alternative implementation for Icehouse as we are refactoring the entire key-value-store system and making memcache a version of that new implementation.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Cheers,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Morgan</div><p style="color:#A0A0A8;">On January 12, 2014 at 10:14:49, Tim Bell (<a href="mailto://tim.bell@cern.ch">tim.bell@cern.ch</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div>Can we tag this patch for backporting to Havana stable ?  

<br>

We're starting work for the CERN upgrade and this looks like a very useful patch to be part of the standard Havana offering.

<br>

<br>Tim

<br>

<br>> -----Original Message-----

<br>> From: Jonathan Proulx [mailto:jon@jonproulx.com]

<br>> Sent: 12 January 2014 18:32

<br>> To: Morgan Fainberg

<br>> Cc: openstack@lists.openstack.org

<br>> Subject: Re: [Openstack] [Keystone] performance issues after havana upgrade

<br>>  

> puzzling side effect?

<br>>  

<br>> I just made a small change to neutron.conf (adjusted a default quota) and restarted neutron-server, now neutron (but not other services)

<br>> is

<br>> spweing:

<br>>  

<br>> Invalid user token - rejecting request

<br>>  

<br>> (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.

<br>>  

> I don't really see how restarting neutron-server could confuse token validation...

<br>>  

<br>>  

<br>> On Sun, Jan 12, 2014 at 10:38 AM, Morgan Fainberg <morgan@metacloud.com> wrote:

<br>> > Thanks for confirming this!  It also validates my new logic going into

<br>> > icehouse (I might have had some ulterior motives here, or not so

<br>> > ulterior as the case may be).  I'll make sure we resolve the test

<br>> > issues (unrelated to the patch) and get it into the Havana tree so you

> > don't need to maintain it outside of the releases.

<br>> >

<br>> > Cheers,

<br>> > Morgan

<br>> >

<br>> > Sent from my tablet-like-device

<br>> >

<br>> >> On Jan 11, 2014, at 11:01 PM, Jonathan Proulx <jon@jonproulx.com> wrote:

<br>> >>

<br>> >>> On Sat, Jan 11, 2014 at 10:57 PM, Morgan Fainberg <m@metacloud.com> wrote:

<br>> >>> Sounds good!  Just remember that prior to the fix I posted there,

<br>> >>> for each token in the user's index, it incurred a round-trip to

<br>> >>> memcached to validate the token wasn't expired.  This change makes

> >>> it so that there are significantly less trips from keystone to memcached.

<br>> >>>

<br>> >>> If this doesn't 100% solve the issue, we should start digging

<br>> >>> further into what is going on, but I am confident this will (at the

> >>> very least) help a reasonable amount.

<br>> >>

> >> You sir are a miracle worker, my hat is off!

<br>> >>

<br>> >> The responsiveness of everything is better than it's ever been, my

> >> users will think this is the best feature the upgrade.

<br>> >>

<br>> >> For example earlier today I managed to launch 10 VMs in parallel,

<br>> >> eventually, I'd guess on the order of 5-10min.  One of my usual

<br>> >> acceptance tests is being able to launch 100 VMs in that time.  Just

<br>> >> now Iaunched 100 in <2min from request until they'd all been

<br>> >> provisioned and were booting.  Now there's too many moving pieces and

<br>> >> too few experimental samples to make any publishable claims, but your

> >> patch is the only thing that changed.

<br>> >>

<br>> >> Thanks,

<br>> >> -Jon

<br>>  

<br>> _______________________________________________

<br>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

<br>> Post to     : openstack@lists.openstack.org

<br>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

<br></div></div></span></blockquote></body></html>