Bug 1125123

Summary: enable multiple keystone-all worker processes
Product: Red Hat OpenStack Reporter: Neependra Khare <nkhare>
Component: openstack-keystoneAssignee: Nathan Kinder <nkinder>
Status: CLOSED WONTFIX QA Contact: Udi Kalifon <ukalifon>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.0 (RHEL 7)CC: aberezin, ayoung, dshaks, yeylon
Target Milestone: z1Keywords: FutureFeature, ZStream
Target Release: 5.0 (RHEL 7)   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-21 17:18:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Neependra Khare 2014-07-31 05:51:53 UTC
Description of problem:

With commit#3580c2af1bd8a8c6574cf4cb7b63bd75b8effad7 in upstream, keystone now supports running multiple keystone-all worker processes. 

I have taken some performance numbers with Devstack with following scenarios:-
1. default keystone settings (single threaded keystone_all process) 
2. by setting public_workers=4 in keytone.conf file, which enable 4 keystone_all worker processes. 

with 2nd scenario performance I see ~4X performance gain. 

Additional info:
It looks upstream is now leaning towards running keystone under httpd
https://bugzilla.redhat.com/show_bug.cgi?id=1111274#c3

but having multiple threads of keystone_all increases the performance significantly. I would like to explore the possibility to back port that patch with RHEL-OSP5 until we don't default to run keystone inside httpd.

Comment 2 Nathan Kinder 2014-08-01 17:32:47 UTC
I would like for the changes to be proven out more upstream.  There were concerns by the Keystone team upstream that this change could expose some parallelism bugs.  These sorts of bugs would most likely be found in real deployment under heavy load as opposed to the gate tests.

This change is also something that would not be backported in Icehouse upstream, so we would have to carry this patch long term for RHEL OSP 5.  This is certainly possible, but it's not ideal.

Comment 4 Arthur Berezin 2014-08-21 17:18:50 UTC
We are also leaning towards defaulting to deploy Keystone under httpd in downstream via OSP-Installer.

I think we should close WONTFIX this BZ, given the maintenance effort needed for the backport throughout OSP5 life cycle, and that direction upstream.