<div dir="ltr">Hi,<div>I have added a blueprint and summit session for ACL. </div><div>I am sure many of the plugin builders are interested in this feature.</div><div>I would like to discuss this during the summit and make it happen in H.</div>
<div style>Please review.</div><div><br></div><div>Ronak<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 29, 2013 at 5:00 AM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [horizon] [*client] WAS [Openstack-stable-maint] Build<br>
failed in Jenkins: periodic-horizon-python27-stable-folsom #178<br>
(Mark McLoughlin)<br>
2. [Doc][LBaaS] API doc for LBaaS extension is ready for review<br>
(Ilya Shakhat)<br>
3. Re: Applying oslo.wsgi back to each project (Russell Bryant)<br>
4. Re: [Quantum] Summit Sessions (Henry Gessau)<br>
5. Re: [keystone] naming case sensitive or not? (Dolph Mathews)<br>
6. Volume encryption (Paul Sarin-Pollet)<br>
7. Re: PCI-passthrough dev ... (Ian Wells)<br>
8. [Savanna] Weekly meeting (#openstack-meeting-alt)<br>
(Sergey Lukjanov)<br>
9. Announcing Heat grizzly-rc2 (Steven Dake)<br>
10. Re: Volume encryption (Bhandaru, Malini K)<br>
11. Re: Volume encryption (Caitlin Bestler)<br>
12. Re: PCI-passthrough dev ... (Irena Berezovsky)<br>
13. Re: PCI-passthrough dev ... (Jiang, Yunhong)<br>
14. Re: [keystone] Keystone handling http requests synchronously<br>
(Adam Young)<br>
15. Re: [keystone] Keystone handling http requests synchronously<br>
(Mike Wilson)<br>
16. Re: PCI-passthrough dev ... (Itzik Brown)<br>
17. [Quantum][LBaaS]- - LBaaS Extension in Quantum Plugin<br>
(Pattabi Ayyasami)<br>
18. Re: Future of Launchpad Answers [Community] (Stefano Maffulli)<br>
19. Re: Future of Launchpad Answers [Community] (Anne Gentle)<br>
20. Re: [Quantum] Summit Sessions (Nachi Ueno)<br>
21. Re: [Quantum][LBaaS]- - LBaaS Extension in Quantum Plugin<br>
(Monty Taylor)<br>
22. Re: [EHO] Project name change [Savanna] (Monty Taylor)<br>
23. Re: [EHO] Project name change [Savanna] (Monty Taylor)<br>
24. Re: [keystone] naming case sensitive or not? (Samuel Merritt)<br>
25. Re: [Quantum][LBaaS]- - LBaaS Extension in Quantum Plugin<br>
(Eugene Nikanorov)<br>
26. Re: [Doc][LBaaS] API doc for LBaaS extension is ready for<br>
review (balaji patnala)<br>
27. Re: [Doc][LBaaS] API doc for LBaaS extension is ready for<br>
review (Ilya Shakhat)<br>
28. Fwd: [keystone] Keystone handling http requests synchronously<br>
(Chmouel Boudjnah)<br>
29. Supporting KMIP in Key Manager (Paul Sarin-Pollet)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 28 Mar 2013 12:13:12 +0000<br>
From: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: openstack-stable-maint<br>
<<a href="mailto:openstack-stable-maint@lists.openstack.org">openstack-stable-maint@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] [*client] WAS<br>
[Openstack-stable-maint] Build failed in Jenkins:<br>
periodic-horizon-python27-stable-folsom #178<br>
Message-ID: <1364472792.9329.102.camel@sorcha><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Hi Alan,<br>
<br>
On Thu, 2013-03-28 at 12:56 +0100, Alan Pevec wrote:<br>
> Hi all,<br>
><br>
> horizon stable/folsom started failing after keystoneclient 0.2.3 last good was<br>
> <a href="https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/168/" target="_blank">https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/168/</a><br>
> with keystoneclient 0.2.2.<br>
><br>
> All OpenStack clients are supposed to be backward compatible, so I'm<br>
> not sure if the solution here is to lock all client version on<br>
> stable/* or is Horizon using keystoneclient internals which aren't<br>
> part of stable API?<br>
<br>
Thanks for finding this. The client libraries definitely aren't supposed<br>
to be breaking their APIs.<br>
<br>
Maybe we can get the backwards incompatible API change reverted and a<br>
new release made?<br>
<br>
Thanks,<br>
Mark.<br>
<br>
> 2013/3/28 OpenStack Jenkins <<a href="mailto:jenkins@openstack.org">jenkins@openstack.org</a>>:<br>
> > See <a href="https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/178/" target="_blank">https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/178/</a><br>
><br>
> ...snip...<br>
><br>
> 2013-03-28 06:04:01.567 | FAIL: test_get_default_role<br>
> (horizon.tests.api_tests.keystone_tests.RoleAPITests)<br>
> 2013-03-28 06:04:01.567 |<br>
> ----------------------------------------------------------------------<br>
> 2013-03-28 06:04:01.567 | Traceback (most recent call last):<br>
> 2013-03-28 06:04:01.568 | File<br>
> "/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/tests/api_tests/keystone_tests.py",<br>
> line 76, in test_get_default_role<br>
> 2013-03-28 06:04:01.568 | keystoneclient = self.stub_keystoneclient()<br>
> 2013-03-28 06:04:01.568 | File<br>
> "/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/test.py",<br>
> line 329, in stub_keystoneclient<br>
> 2013-03-28 06:04:01.568 | self.keystoneclient =<br>
> self.mox.CreateMock(keystone_client.Client)<br>
> 2013-03-28 06:04:01.568 | File<br>
> "/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py",<br>
> line 258, in CreateMock<br>
> 2013-03-28 06:04:01.568 | new_mock = MockObject(class_to_mock, attrs=attrs)<br>
> 2013-03-28 06:04:01.568 | File<br>
> "/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py",<br>
> line 556, in __init__<br>
> 2013-03-28 06:04:01.568 | attr = getattr(class_to_mock, method)<br>
> 2013-03-28 06:04:01.568 | File<br>
> "/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py",<br>
> line 608, in __getattr__<br>
> 2013-03-28 06:04:01.568 | raise UnknownMethodCallError(name)<br>
> 2013-03-28 06:04:01.568 | UnknownMethodCallError: Method called is not<br>
> a member of the object: Method called is not a member of the object:<br>
> auth_token<br>
> 2013-03-28 06:04:01.568 | >> raise UnknownMethodCallError('auth_token')<br>
><br>
> ...snip...<br>
><br>
> 2013-03-28 06:04:03.188 | python-keystoneclient==0.2.3<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 28 Mar 2013 16:13:35 +0400<br>
From: Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>><br>
To: "OpenStack Development Mailing List<br>
(<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Doc][LBaaS] API doc for LBaaS extension is<br>
ready for review<br>
Message-ID:<br>
<<a href="mailto:CAMzOD1%2BrhmYSm9FEQ5HBdDkfbGPGaSUWbuerbkC_C-fiTmAtYA@mail.gmail.com">CAMzOD1+rhmYSm9FEQ5HBdDkfbGPGaSUWbuerbkC_C-fiTmAtYA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
Please review a new section in API docs describing LBaaS extension. Review<br>
is <a href="https://review.openstack.org/#/c/25409/" target="_blank">https://review.openstack.org/#/c/25409/</a><br>
The text is partially based on<br>
<a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0</a> . Requests and<br>
responses are captured from traffic between python-client and quantum, thus<br>
may slightly differ from what documented on wiki.<br>
<br>
Thanks,<br>
Ilya<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/59c524e5/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/59c524e5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 28 Mar 2013 09:07:31 -0400<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Applying oslo.wsgi back to each project<br>
Message-ID: <<a href="mailto:51544093.1050603@redhat.com">51544093.1050603@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 03/28/2013 04:15 AM, Zhongyue Luo wrote:<br>
> Hi all,<br>
><br>
> I noticed that one of the modules being totally ignored in oslo is<br>
> wsgi.py which should actually be used in most of the OpenStack projects.<br>
> (Based on zero results from a "find . -name "openstack-common.conf"<br>
> -exec grep -l wsgi {} \;")<br>
><br>
> Before it's too late, we should apply what is currently available and<br>
> avoid further divergence of code.<br>
<br>
On a related note: <a href="http://summit.openstack.org/cfp/details/12" target="_blank">http://summit.openstack.org/cfp/details/12</a><br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 28 Mar 2013 10:00:58 -0400<br>
From: Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Summit Sessions<br>
Message-ID: <<a href="mailto:51544D1A.7040202@cisco.com">51544D1A.7040202@cisco.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Nachi,<br>
<br>
Thanks for bringing this to my attention. My initial reaction is that, yes,<br>
it should be covered by QoS. I will refer to it in my write-up for the QoS<br>
proposal, and keep in touch with you for a potential merge.<br>
<br>
-- Henry<br>
<br>
On Wed, Mar 27, at 7:56 pm, Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>> wrote:<br>
<br>
> Hi<br>
><br>
> I'm also planning to implement related feature in H.<br>
> BP <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-control-on-external-gateway" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-control-on-external-gateway</a><br>
><br>
> Basically, I wanna stop exhaust of external network connection by one tenant<br>
><br>
> May be we can merge our proposals.<br>
> Your qos api is per port based one?<br>
><br>
> Regards<br>
> Nachi<br>
><br>
> 2013/3/27 Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>>:<br>
>> I will be adding some more details to the proposal soon.<br>
>><br>
>> -- Henry<br>
>><br>
>> On Wed, Mar 27, at 10:50 am, gong yong sheng <<a href="mailto:gongysh@linux.vnet.ibm.com">gongysh@linux.vnet.ibm.com</a>> wrote:<br>
>><br>
>>> It will help if u can have some design before summit discuss.<br>
>>> On 03/27/2013 10:33 PM, Sean M. Collins wrote:<br>
>>>> I'd like to get the QoS API proposal in as well.<br>
>>>><br>
>>>> <a href="http://summit.openstack.org/cfp/details/160" target="_blank">http://summit.openstack.org/cfp/details/160</a><br>
>>>><br>
>>>> I am currently working with Comcast, and this is a must-have feature in<br>
>>>> Quantum.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 28 Mar 2013 10:06:14 -0500<br>
From: Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [keystone] naming case sensitive or not?<br>
Message-ID:<br>
<CAC=<a href="mailto:h7gXJhb7szVksa71UVmS0_AGjF2hZAY9agc7T23DkbBZ3Fw@mail.gmail.com">h7gXJhb7szVksa71UVmS0_AGjF2hZAY9agc7T23DkbBZ3Fw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
That's basically up to the identity driver in use -- for example, with the<br>
SQL driver, if your database is case sensitive, then keystone will be as<br>
well.<br>
<br>
If the driver is case sensitive, you should have gotten a 409 Conflict back<br>
on your second example command.<br>
<br>
<br>
-Dolph<br>
<br>
<br>
On Thu, Mar 28, 2013 at 5:57 AM, Hua ZZ Zhang <<a href="mailto:zhuadl@cn.ibm.com">zhuadl@cn.ibm.com</a>> wrote:<br>
<br>
> Dears,<br>
><br>
> I have a question about keystone case sensitive of naming, such as user<br>
> name, tenant name, role name.<br>
> Are they case sensitive or not?<br>
><br>
> I test the command below but it failed. so my conclusion is case<br>
> insensitive.<br>
> keystone user-create --name Usera --pass xyz<br>
> keystone user-create --name UserA --pass xyz<br>
><br>
> *Best Regards, *<br>
><br>
> ------------------------------<br>
><br>
> *Edward Zhang(??)*<br>
> Advisory Software Engineer<br>
> Software Standards & Open Source Software<br>
> Emerging Technology Institute(ETI)<br>
> IBM China Software Development Lab<br>
> e-mail: <a href="mailto:zhuadl@cn.ibm.com">zhuadl@cn.ibm.com</a><br>
> Notes ID: Hua ZZ Zhang/China/IBM<br>
> Tel: 86-10-82450483<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: C4797729.gif<br>
Type: image/gif<br>
Size: 1279 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0002.gif" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0002.gif</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: ecblank.gif<br>
Type: image/gif<br>
Size: 45 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0003.gif" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/19c2c5b8/attachment-0003.gif</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 28 Mar 2013 17:35:33 +0100<br>
From: "Paul Sarin-Pollet" <<a href="mailto:psarpol@gmx.com">psarpol@gmx.com</a>><br>
To: "OpenStack Development Mailing List"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Volume encryption<br>
Message-ID: <<a href="mailto:20130328163533.67820@gmx.com">20130328163533.67820@gmx.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
<br>
Dou you think it could be possible to add an option to let the user enter his own key ?<br>
The key would not be stored by the CSP and would be under the user responsability.<br>
<br>
Thanks<br>
<br>
Paul<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/de4629d5/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/de4629d5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Thu, 28 Mar 2013 18:29:46 +0100<br>
From: Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
Message-ID:<br>
<CAPoubz4UUL=<a href="mailto:WKiDazpukCsU-9tR2B8N2wOCQHgaOV9q%2Bzm6%2BUQ@mail.gmail.com">WKiDazpukCsU-9tR2B8N2wOCQHgaOV9q+zm6+UQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Chuck's is not the only summit session:<br>
<br>
<a href="http://summit.openstack.org/cfp/details/81" target="_blank">http://summit.openstack.org/cfp/details/81</a> (the Quantum side of things if<br>
you're mapping network devices)<br>
<br>
... and I know Mellanox have also been working on that particular side of<br>
things too. Perhaps we could all get together at the summit before the<br>
sessions for a show and tell? We could equally work it all out in the<br>
sessions, but it seems it would be hard to lead a session like that without<br>
having some knowledge up front of what other people have done.<br>
<br>
To be fair, our code is basically Vladimir Popovski's (Zardara Storage's)<br>
work, tidied up and with a scheduler check to make sure there are actually<br>
available SRIOV functions on the node before scheduling. It's there, it's<br>
actually a patch against Folsom at the moment, and it works, but I wouldn't<br>
lay claim to it necessarily being the One True Way to implement this (and I<br>
don't think it has tests enough to pass a review).<br>
--<br>
Ian.<br>
<br>
<br>
<br>
On 25 March 2013 16:23, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
<br>
> On 03/24/2013 01:44 PM, Ian Wells wrote:<br>
> > Yep, we've got code in test at the moment.<br>
><br>
> This is (at least) the second instance that I've heard of where PCI<br>
> passthrough has been implemented, but code hasn't surfaced yet. It's<br>
> really unfortunate to see the duplication of effort happening.<br>
><br>
> Chuck Short also proposed a design summit session on it, presumably to<br>
> discuss implementing it yet another time:<br>
><br>
> <a href="http://summit.openstack.org/cfp/details/29" target="_blank">http://summit.openstack.org/cfp/details/29</a><br>
><br>
> It would be really nice to get some code out in the open for this. :-)<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/2dcb0afc/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/2dcb0afc/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Thu, 28 Mar 2013 21:46:33 +0400<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: "<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>>,<br>
"<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: "<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>>, "<a href="mailto:eho@lists.launchpad.net">eho@lists.launchpad.net</a>"<br>
<<a href="mailto:eho@lists.launchpad.net">eho@lists.launchpad.net</a>><br>
Subject: [openstack-dev] [Savanna] Weekly meeting<br>
(#openstack-meeting-alt)<br>
Message-ID: <<a href="mailto:07AC732E-CF27-4B8A-B124-C29831BF5E4F@mirantis.com">07AC732E-CF27-4B8A-B124-C29831BF5E4F@mirantis.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi,<br>
<br>
Today there will be our third weekly community meeting about Savanna at 18:00 UTC on irc channel #openstack-meeting-alt at freenode.<br>
<br>
Come along.<br>
<br>
Sergey Lukjanov<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Thu, 28 Mar 2013 10:49:25 -0700<br>
From: Steven Dake <<a href="mailto:sdake@redhat.com">sdake@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Announcing Heat grizzly-rc2<br>
Message-ID: <<a href="mailto:515482A5.9080705@redhat.com">515482A5.9080705@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Hi folks!<br>
<br>
Grizzly rc2 is available for testing. A big thanks to Steve Baker and<br>
Steve Hardy for their patches for this release.<br>
<br>
Heat rc2 can be downloaded from:<br>
<br>
<a href="https://launchpad.net/heat/grizzly/grizzly-rc2/+download/heat-2013.1.rc2.tar.gz" target="_blank">https://launchpad.net/heat/grizzly/grizzly-rc2/+download/heat-2013.1.rc2.tar.gz</a><br>
<br>
Regards<br>
-steve<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Thu, 28 Mar 2013 17:58:35 +0000<br>
From: "Bhandaru, Malini K" <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Volume encryption<br>
Message-ID:<br>
<<a href="mailto:EE6FFF4F6C34C84C8C98DD2414EEA47E520A122D@FMSMSX105.amr.corp.intel.com">EE6FFF4F6C34C84C8C98DD2414EEA47E520A122D@FMSMSX105.amr.corp.intel.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Paul,<br>
<br>
I am guessing you are referring to volume encryption because for plain object encryption OpenStack can be oblivious of any encryption,<br>
Just put/get is adequate with the user taking care of encryption/decryption.<br>
<br>
The volume APIs could definitely take in an argument with the key-string, so during communications, whatever protocol is in effect, the key-string<br>
will be transmitted using SSL/TLS or IPSEC or in the clear.<br>
Where we save <key-id> in the meta data for the volume we could instead save a marker saying ?EXTERNAL_KEY? or ?USER_KEY? or something to that effect. It indicates the volume is encrypted, as opposed to plain text.<br>
<br>
Regards<br>
Malini<br>
From: Paul Sarin-Pollet [mailto:<a href="mailto:psarpol@gmx.com">psarpol@gmx.com</a>]<br>
Sent: Thursday, March 28, 2013 9:36 AM<br>
To: OpenStack Development Mailing List<br>
Subject: [openstack-dev] Volume encryption<br>
<br>
Hi all,<br>
<br>
Dou you think it could be possible to add an option to let the user enter his own key ?<br>
The key would not be stored by the CSP and would be under the user responsibility.<br>
<br>
Thanks<br>
<br>
Paul<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/46848173/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/46848173/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 28 Mar 2013 19:57:06 +0000<br>
From: Caitlin Bestler <<a href="mailto:Caitlin.Bestler@nexenta.com">Caitlin.Bestler@nexenta.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Volume encryption<br>
Message-ID: <719CD19D2B2BFA4CB1B3F00D2A8CDCD0C50C147D@AUSP01DAG0106><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
<br>
Paul Sarin-Pollet wrote:<br>
<br>
> Dou you think it could be possible to add an option to let the user enter his own key ?<br>
> The key would not be stored by the CSP and would be under the user responsability.<br>
<br>
<br>
If the user holds and is responsible for the key, why would the user want to communicate<br>
the key over the network for the purpose of concentrating the encrypt/decrypt heavy lifting<br>
onto the centralized storage server, rather than doing the encrypting/decrypting itself?<br>
<br>
When the users do not maintain the key is when it makes sense to do the encryption/decryption<br>
on the storage server.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/05f26419/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/05f26419/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Thu, 28 Mar 2013 19:58:29 +0000<br>
From: Irena Berezovsky <<a href="mailto:irenab@mellanox.com">irenab@mellanox.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
Message-ID:<br>
<<a href="mailto:9D25E123B44F4A4291F4B5C13DA94E7773520335@MTLDAG02.mtl.com">9D25E123B44F4A4291F4B5C13DA94E7773520335@MTLDAG02.mtl.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Ian,<br>
I think it is a good idea to get together before the design summit sessions to share the experience and discuss the work done in SRIOV area.<br>
Any idea how to arrange it?<br>
<br>
Regards,<br>
Irena<br>
<br>
From: Ian Wells [mailto:<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>]<br>
Sent: Thursday, March 28, 2013 7:39 PM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
<br>
Chuck's is not the only summit session:<br>
<br>
<a href="http://summit.openstack.org/cfp/details/81" target="_blank">http://summit.openstack.org/cfp/details/81</a> (the Quantum side of things if you're mapping network devices)<br>
<br>
... and I know Mellanox have also been working on that particular side of things too. Perhaps we could all get together at the summit before the sessions for a show and tell? We could equally work it all out in the sessions, but it seems it would be hard to lead a session like that without having some knowledge up front of what other people have done.<br>
<br>
To be fair, our code is basically Vladimir Popovski's (Zardara Storage's) work, tidied up and with a scheduler check to make sure there are actually available SRIOV functions on the node before scheduling. It's there, it's actually a patch against Folsom at the moment, and it works, but I wouldn't lay claim to it necessarily being the One True Way to implement this (and I don't think it has tests enough to pass a review).<br>
--<br>
Ian.<br>
<br>
<br>
On 25 March 2013 16:23, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
On 03/24/2013 01:44 PM, Ian Wells wrote:<br>
> Yep, we've got code in test at the moment.<br>
This is (at least) the second instance that I've heard of where PCI<br>
passthrough has been implemented, but code hasn't surfaced yet. It's<br>
really unfortunate to see the duplication of effort happening.<br>
<br>
Chuck Short also proposed a design summit session on it, presumably to<br>
discuss implementing it yet another time:<br>
<br>
<a href="http://summit.openstack.org/cfp/details/29" target="_blank">http://summit.openstack.org/cfp/details/29</a><br>
<br>
It would be really nice to get some code out in the open for this. :-)<br>
<br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/83bc15be/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/83bc15be/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Thu, 28 Mar 2013 20:20:03 +0000<br>
From: "Jiang, Yunhong" <<a href="mailto:yunhong.jiang@intel.com">yunhong.jiang@intel.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
Message-ID:<br>
<<a href="mailto:DDCAE26804250545B9934A2056554AA0017A7B0E@ORSMSX107.amr.corp.intel.com">DDCAE26804250545B9934A2056554AA0017A7B0E@ORSMSX107.amr.corp.intel.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Yes, <a href="http://summit.openstack.org/cfp/details/80" target="_blank">http://summit.openstack.org/cfp/details/80</a> is the one for nova.<br>
<br>
If this topic will be accepted, a discussion on mailing list can get more input and idea, thus the session will be more effective. And a 'show and tell' before the session is a good idea<br>
<br>
Thanks<br>
--jyh<br>
<br>
From: Ian Wells [mailto:<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>]<br>
Sent: Thursday, March 28, 2013 10:30 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
<br>
Chuck's is not the only summit session:<br>
<br>
<a href="http://summit.openstack.org/cfp/details/81" target="_blank">http://summit.openstack.org/cfp/details/81</a> (the Quantum side of things if you're mapping network devices)<br>
<br>
... and I know Mellanox have also been working on that particular side of things too. Perhaps we could all get together at the summit before the sessions for a show and tell? We could equally work it all out in the sessions, but it seems it would be hard to lead a session like that without having some knowledge up front of what other people have done.<br>
<br>
To be fair, our code is basically Vladimir Popovski's (Zardara Storage's) work, tidied up and with a scheduler check to make sure there are actually available SRIOV functions on the node before scheduling. It's there, it's actually a patch against Folsom at the moment, and it works, but I wouldn't lay claim to it necessarily being the One True Way to implement this (and I don't think it has tests enough to pass a review).<br>
--<br>
Ian.<br>
<br>
<br>
On 25 March 2013 16:23, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
On 03/24/2013 01:44 PM, Ian Wells wrote:<br>
> Yep, we've got code in test at the moment.<br>
This is (at least) the second instance that I've heard of where PCI<br>
passthrough has been implemented, but code hasn't surfaced yet. It's<br>
really unfortunate to see the duplication of effort happening.<br>
<br>
Chuck Short also proposed a design summit session on it, presumably to<br>
discuss implementing it yet another time:<br>
<br>
<a href="http://summit.openstack.org/cfp/details/29" target="_blank">http://summit.openstack.org/cfp/details/29</a><br>
<br>
It would be really nice to get some code out in the open for this. :-)<br>
<br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/557edca4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/557edca4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Thu, 28 Mar 2013 17:04:21 -0400<br>
From: Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [keystone] Keystone handling http<br>
requests synchronously<br>
Message-ID: <<a href="mailto:5154B055.4030004@redhat.com">5154B055.4030004@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 03/26/2013 01:34 PM, David Kranz wrote:<br>
> This is without memcache in auth_token. I was trying to find a way<br>
> past <a href="https://bugs.launchpad.net/keystone/+bug/1020127" target="_blank">https://bugs.launchpad.net/keystone/+bug/1020127</a><br>
> which I think I now have. I would appreciate it if you could validate<br>
> my comment at the end of that ticket. Here, I just thought that the<br>
> keystone<br>
> throughput was very low. I know that swift should not be hitting it so<br>
> hard. If you were referring to using memcache in the keystone server<br>
> itself then<br>
You can use memcached as an alternate token back end, but I have no<br>
reason to thin it would perform any better than SQL. It was broken<br>
until fairly recently, too, so I suspect it is not used much in the wild.<br>
<br>
<br>
> I didn't know you could do that.<br>
><br>
> -David<br>
><br>
><br>
><br>
> On 3/26/2013 12:33 PM, Chmouel Boudjnah wrote:<br>
>> this seems to be pretty low, do you have memcaching enabled?<br>
>><br>
>> On Tue, Mar 26, 2013 at 4:20 PM, David Kranz <<a href="mailto:david.kranz@qrclab.com">david.kranz@qrclab.com</a>><br>
>> wrote:<br>
>>> Related to this, I measured that the rate at which keystone (running<br>
>>> on a<br>
>>> real fairly hefty server) can handle the requests coming from the<br>
>>> auth_token<br>
>>> middleware (no pki tokens) is about 16/s. That seems pretty low to<br>
>>> me. Is<br>
>>> there some other keystone performance problem here, or is that not<br>
>>> surprising?<br>
>>><br>
>>> -David<br>
>>><br>
>>><br>
>>> On 3/24/2013 9:11 PM, Jay Pipes wrote:<br>
>>>> Sure, you could do that, of course. Just like you could use<br>
>>>> gunicorn or<br>
>>>> some other web server. Just like you could deploy any of the other<br>
>>>> OpenStack services that way.<br>
>>>><br>
>>>> It would just be nice if one could configure Keystone in the same<br>
>>>> manner<br>
>>>> that all the other OpenStack services are configured.<br>
>>>><br>
>>>> -jay<br>
>>>><br>
>>>> On 03/23/2013 01:19 PM, Joshua Harlow wrote:<br>
>>>>> See: <a href="https://github.com/openstack/keystone/tree/master/httpd" target="_blank">https://github.com/openstack/keystone/tree/master/httpd</a><br>
>>>>><br>
>>>>> For example...<br>
>>>>><br>
>>>>> This lets apache do the multiprocess instead of how nova, glance ...<br>
>>>>> have basically recreated the same mechanism that apache has had for<br>
>>>>> years.<br>
>>>>><br>
>>>>> Sent from my really tiny device...<br>
>>>>><br>
>>>>> On Mar 23, 2013, at 10:14 AM, "Joshua Harlow" <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a><br>
>>>>> <mailto:<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>>> wrote:<br>
>>>>><br>
>>>>>> Or I think u can run keystone in wsgi+apache easily, thus getting<br>
>>>>>> u the<br>
>>>>>> multiprocess support via apache worker processes.<br>
>>>>>><br>
>>>>>> Sent from my really tiny<br>
>>>>>> device....<br>
>>>>>><br>
>>>>>> On Mar 22, 2013, at 10:47 AM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
>>>>>> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>>> Unfortunately, Keystone's WSGI server is only a single process,<br>
>>>>>> with a<br>
>>>>>>> greenthread pool. Unlike Glance, Nova, Cinder, and Swift, which all<br>
>>>>>> use<br>
>>>>>>> multi-process, greenthread-pool-per-process WSGI servers[1],<br>
>>>>>> Keystone<br>
>>>>>>> does it differently[2].<br>
>>>>>>><br>
>>>>>>> There was a patchset[3] that added<br>
>>>>>> multiprocess support to Keystone, but<br>
>>>>>>> due to objections from termie and<br>
>>>>>> others about it not being necessary,<br>
>>>>>>> it died on the vine. Termie even<br>
>>>>>> noted that Keystone "was designed to be<br>
>>>>>>> run as multiple instances and load<br>
>>>>>> balanced over and [he felt] that<br>
>>>>>>> should be the preferred scaling point".<br>
>>>>>>><br>
>>>>>>> Because the mysql client connection is C-based, calls to it will be<br>
>>>>>>><br>
>>>>>> blocking operations on greenthreads within a single process, meaning<br>
>>>>>>> even<br>
>>>>>> if multiple greenthreads are spawned for those 200 incoming<br>
>>>>>>> requests, they<br>
>>>>>> will be processed synchronously.<br>
>>>>>>> The solution is for Keystone to<br>
>>>>>> implement the same multi-processed WSGI<br>
>>>>>>> worker stuff that is in the other<br>
>>>>>> OpenStack projects. Or, diverge from<br>
>>>>>>> the deployment solution of Nova,<br>
>>>>>> Glance, Cinder, and Swift, and manually<br>
>>>>>>> run multiple instances of<br>
>>>>>> keystone, as Termie suggests.<br>
>>>>>>> Best,<br>
>>>>>>> -jay<br>
>>>>>>><br>
>>>>>>> [1] All pretty much<br>
>>>>>> derived from the original Swift code, with some Oslo<br>
>>>>>>> improvements around<br>
>>>>>> config<br>
>>>>>>> [2] Compare<br>
>>>>>>><br>
>>>>>> <a href="https://github.com/openstack/glance/blob/master/glance/common/wsgi.py" target="_blank">https://github.com/openstack/glance/blob/master/glance/common/wsgi.py</a><br>
>>>>>><br>
>>>>>> with<br>
>>>>>><br>
>>>>>> <a href="https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py</a><br>
>>>>>><br>
>>>>>> [3] <a href="https://review.openstack.org/#/c/7017/" target="_blank">https://review.openstack.org/#/c/7017/</a><br>
>>>>>>> On 03/21/2013 07:45 AM,<br>
>>>>>> Kanade, Rohan wrote:<br>
>>>>>>>> Hi,<br>
>>>>>>>><br>
>>>>>>>> I was trying to create 200 users using<br>
>>>>>> the keystone client. All the<br>
>>>>>>>> users are unique and are created on separate<br>
>>>>>> threads which are started<br>
>>>>>>>> at the same time.<br>
>>>>>>>><br>
>>>>>>>> keystone is handling<br>
>>>>>> each request synchronously , i.e. user 1 is<br>
>>>>>>>> created, then user 2 is<br>
>>>>>> created ...<br>
>>>>>>>> Shouldnt keystone be running a greenthread for each<br>
>>>>>> request and try to<br>
>>>>>>>> create these users asynchronously?<br>
>>>>>>>> like start<br>
>>>>>> creating user 1 , while handling that request, start creating<br>
>>>>>>>> user 2 or<br>
>>>>>> user n...<br>
>>>>>>>> I have attached the keystone service logs for further<br>
>>>>>> assistance.<br>
>>>>>>>> <a href="http://paste.openstack.org/show/34216/" target="_blank">http://paste.openstack.org/show/34216/</a><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>><br>
>>>>>> Disclaimer:This email and any attachments are sent in strictest<br>
>>>>>> confidence for the sole use of the addressee and may contain legally<br>
>>>>>> privileged, confidential, and proprietary data. If you are not the<br>
>>>>>> intended recipient, please advise the sender by replying promptly to<br>
>>>>>>>> this<br>
>>>>>> email and then delete and destroy this email and any attachments<br>
>>>>>>>> without<br>
>>>>>> any further use, copying or forwarding<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>>>> OpenStack-dev mailing<br>
>>>>>> list<br>
>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>>> OpenStack-dev mailing<br>
>>>>>> list<br>
>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Thu, 28 Mar 2013 15:13:43 -0600<br>
From: Mike Wilson <<a href="mailto:geekinutah@gmail.com">geekinutah@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [keystone] Keystone handling http<br>
requests synchronously<br>
Message-ID:<br>
<<a href="mailto:CAFshShPRBooX%2B5MXDWfiz7mMwetC9X_vXYtp-9H5tFr6yRvhzA@mail.gmail.com">CAFshShPRBooX+5MXDWfiz7mMwetC9X_vXYtp-9H5tFr6yRvhzA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Actually, Bluehost is using it in production. We couldn't get past a couple<br>
thousand nodes without it because of the amount of requests that the<br>
quantum network driver produces (5 every periodic interval per compute<br>
node). It does have some problems if one tenant builds up a large list of<br>
tokens, but other than that it has been great for us. I think our<br>
deployment is somewhere around 15,000 nodes right now and it is still<br>
holding up strong. It is MUCH more performant than just a plain SQL backend.<br>
<br>
<br>
On Thu, Mar 28, 2013 at 3:04 PM, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
<br>
> On 03/26/2013 01:34 PM, David Kranz wrote:<br>
><br>
>> This is without memcache in auth_token. I was trying to find a way past<br>
>> <a href="https://bugs.launchpad.net/**keystone/+bug/1020127" target="_blank">https://bugs.launchpad.net/**keystone/+bug/1020127</a><<a href="https://bugs.launchpad.net/keystone/+bug/1020127" target="_blank">https://bugs.launchpad.net/keystone/+bug/1020127</a>><br>
>> which I think I now have. I would appreciate it if you could validate my<br>
>> comment at the end of that ticket. Here, I just thought that the keystone<br>
>> throughput was very low. I know that swift should not be hitting it so<br>
>> hard. If you were referring to using memcache in the keystone server itself<br>
>> then<br>
>><br>
> You can use memcached as an alternate token back end, but I have no<br>
> reason to thin it would perform any better than SQL. It was broken until<br>
> fairly recently, too, so I suspect it is not used much in the wild.<br>
><br>
><br>
><br>
> I didn't know you could do that.<br>
>><br>
>> -David<br>
>><br>
>><br>
>><br>
>> On 3/26/2013 12:33 PM, Chmouel Boudjnah wrote:<br>
>><br>
>>> this seems to be pretty low, do you have memcaching enabled?<br>
>>><br>
>>> On Tue, Mar 26, 2013 at 4:20 PM, David Kranz <<a href="mailto:david.kranz@qrclab.com">david.kranz@qrclab.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> Related to this, I measured that the rate at which keystone (running on<br>
>>>> a<br>
>>>> real fairly hefty server) can handle the requests coming from the<br>
>>>> auth_token<br>
>>>> middleware (no pki tokens) is about 16/s. That seems pretty low to me.<br>
>>>> Is<br>
>>>> there some other keystone performance problem here, or is that not<br>
>>>> surprising?<br>
>>>><br>
>>>> -David<br>
>>>><br>
>>>><br>
>>>> On 3/24/2013 9:11 PM, Jay Pipes wrote:<br>
>>>><br>
>>>>> Sure, you could do that, of course. Just like you could use gunicorn or<br>
>>>>> some other web server. Just like you could deploy any of the other<br>
>>>>> OpenStack services that way.<br>
>>>>><br>
>>>>> It would just be nice if one could configure Keystone in the same<br>
>>>>> manner<br>
>>>>> that all the other OpenStack services are configured.<br>
>>>>><br>
>>>>> -jay<br>
>>>>><br>
>>>>> On 03/23/2013 01:19 PM, Joshua Harlow wrote:<br>
>>>>><br>
>>>>>> See: <a href="https://github.com/openstack/**keystone/tree/master/httpd" target="_blank">https://github.com/openstack/**keystone/tree/master/httpd</a><<a href="https://github.com/openstack/keystone/tree/master/httpd" target="_blank">https://github.com/openstack/keystone/tree/master/httpd</a>><br>
>>>>>><br>
>>>>>> For example...<br>
>>>>>><br>
>>>>>> This lets apache do the multiprocess instead of how nova, glance ...<br>
>>>>>> have basically recreated the same mechanism that apache has had for<br>
>>>>>> years.<br>
>>>>>><br>
>>>>>> Sent from my really tiny device...<br>
>>>>>><br>
>>>>>> On Mar 23, 2013, at 10:14 AM, "Joshua Harlow" <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a><br>
>>>>>> <mailto:<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>**>> wrote:<br>
>>>>>><br>
>>>>>> Or I think u can run keystone in wsgi+apache easily, thus getting u<br>
>>>>>>> the<br>
>>>>>>> multiprocess support via apache worker processes.<br>
>>>>>>><br>
>>>>>>> Sent from my really tiny<br>
>>>>>>> device....<br>
>>>>>>><br>
>>>>>>> On Mar 22, 2013, at 10:47 AM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
>>>>>>> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>><br>
>>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Unfortunately, Keystone's WSGI server is only a single process,<br>
>>>>>>>><br>
>>>>>>> with a<br>
>>>>>>><br>
>>>>>>>> greenthread pool. Unlike Glance, Nova, Cinder, and Swift, which all<br>
>>>>>>>><br>
>>>>>>> use<br>
>>>>>>><br>
>>>>>>>> multi-process, greenthread-pool-per-process WSGI servers[1],<br>
>>>>>>>><br>
>>>>>>> Keystone<br>
>>>>>>><br>
>>>>>>>> does it differently[2].<br>
>>>>>>>><br>
>>>>>>>> There was a patchset[3] that added<br>
>>>>>>>><br>
>>>>>>> multiprocess support to Keystone, but<br>
>>>>>>><br>
>>>>>>>> due to objections from termie and<br>
>>>>>>>><br>
>>>>>>> others about it not being necessary,<br>
>>>>>>><br>
>>>>>>>> it died on the vine. Termie even<br>
>>>>>>>><br>
>>>>>>> noted that Keystone "was designed to be<br>
>>>>>>><br>
>>>>>>>> run as multiple instances and load<br>
>>>>>>>><br>
>>>>>>> balanced over and [he felt] that<br>
>>>>>>><br>
>>>>>>>> should be the preferred scaling point".<br>
>>>>>>>><br>
>>>>>>>> Because the mysql client connection is C-based, calls to it will be<br>
>>>>>>>><br>
>>>>>>>> blocking operations on greenthreads within a single process,<br>
>>>>>>> meaning<br>
>>>>>>><br>
>>>>>>>> even<br>
>>>>>>>><br>
>>>>>>> if multiple greenthreads are spawned for those 200 incoming<br>
>>>>>>><br>
>>>>>>>> requests, they<br>
>>>>>>>><br>
>>>>>>> will be processed synchronously.<br>
>>>>>>><br>
>>>>>>>> The solution is for Keystone to<br>
>>>>>>>><br>
>>>>>>> implement the same multi-processed WSGI<br>
>>>>>>><br>
>>>>>>>> worker stuff that is in the other<br>
>>>>>>>><br>
>>>>>>> OpenStack projects. Or, diverge from<br>
>>>>>>><br>
>>>>>>>> the deployment solution of Nova,<br>
>>>>>>>><br>
>>>>>>> Glance, Cinder, and Swift, and manually<br>
>>>>>>><br>
>>>>>>>> run multiple instances of<br>
>>>>>>>><br>
>>>>>>> keystone, as Termie suggests.<br>
>>>>>>><br>
>>>>>>>> Best,<br>
>>>>>>>> -jay<br>
>>>>>>>><br>
>>>>>>>> [1] All pretty much<br>
>>>>>>>><br>
>>>>>>> derived from the original Swift code, with some Oslo<br>
>>>>>>><br>
>>>>>>>> improvements around<br>
>>>>>>>><br>
>>>>>>> config<br>
>>>>>>><br>
>>>>>>>> [2] Compare<br>
>>>>>>>><br>
>>>>>>>> <a href="https://github.com/openstack/**glance/blob/master/glance/**" target="_blank">https://github.com/openstack/**glance/blob/master/glance/**</a><br>
>>>>>>> common/wsgi.py<<a href="https://github.com/openstack/glance/blob/master/glance/common/wsgi.py" target="_blank">https://github.com/openstack/glance/blob/master/glance/common/wsgi.py</a>><br>
>>>>>>> with<br>
>>>>>>><br>
>>>>>>> <a href="https://github.com/openstack/**keystone/blob/master/keystone/**" target="_blank">https://github.com/openstack/**keystone/blob/master/keystone/**</a><br>
>>>>>>> common/wsgi.py<<a href="https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py</a>><br>
>>>>>>> [3] <a href="https://review.openstack.org/#**/c/7017/" target="_blank">https://review.openstack.org/#**/c/7017/</a><<a href="https://review.openstack.org/#/c/7017/" target="_blank">https://review.openstack.org/#/c/7017/</a>><br>
>>>>>>><br>
>>>>>>>> On 03/21/2013 07:45 AM,<br>
>>>>>>>><br>
>>>>>>> Kanade, Rohan wrote:<br>
>>>>>>><br>
>>>>>>>> Hi,<br>
>>>>>>>>><br>
>>>>>>>>> I was trying to create 200 users using<br>
>>>>>>>>><br>
>>>>>>>> the keystone client. All the<br>
>>>>>>><br>
>>>>>>>> users are unique and are created on separate<br>
>>>>>>>>><br>
>>>>>>>> threads which are started<br>
>>>>>>><br>
>>>>>>>> at the same time.<br>
>>>>>>>>><br>
>>>>>>>>> keystone is handling<br>
>>>>>>>>><br>
>>>>>>>> each request synchronously , i.e. user 1 is<br>
>>>>>>><br>
>>>>>>>> created, then user 2 is<br>
>>>>>>>>><br>
>>>>>>>> created ...<br>
>>>>>>><br>
>>>>>>>> Shouldnt keystone be running a greenthread for each<br>
>>>>>>>>><br>
>>>>>>>> request and try to<br>
>>>>>>><br>
>>>>>>>> create these users asynchronously?<br>
>>>>>>>>> like start<br>
>>>>>>>>><br>
>>>>>>>> creating user 1 , while handling that request, start creating<br>
>>>>>>><br>
>>>>>>>> user 2 or<br>
>>>>>>>>><br>
>>>>>>>> user n...<br>
>>>>>>><br>
>>>>>>>> I have attached the keystone service logs for further<br>
>>>>>>>>><br>
>>>>>>>> assistance.<br>
>>>>>>><br>
>>>>>>>> <a href="http://paste.openstack.org/**show/34216/" target="_blank">http://paste.openstack.org/**show/34216/</a><<a href="http://paste.openstack.org/show/34216/" target="_blank">http://paste.openstack.org/show/34216/</a>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> ______________________________**______________________________**__________<br>
>>>>>>><br>
>>>>>>> Disclaimer:This email and any attachments are sent in strictest<br>
>>>>>>> confidence for the sole use of the addressee and may contain legally<br>
>>>>>>> privileged, confidential, and proprietary data. If you are not the<br>
>>>>>>> intended recipient, please advise the sender by replying promptly to<br>
>>>>>>><br>
>>>>>>>> this<br>
>>>>>>>>><br>
>>>>>>>> email and then delete and destroy this email and any attachments<br>
>>>>>>><br>
>>>>>>>> without<br>
>>>>>>>>><br>
>>>>>>>> any further use, copying or forwarding<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> ______________________________**_________________<br>
>>>>>>><br>
>>>>>>>> OpenStack-dev mailing<br>
>>>>>>>>><br>
>>>>>>>> list<br>
>>>>>>><br>
>>>>>>>> OpenStack-dev@lists.openstack.**org<<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.">OpenStack-dev@lists.</a>**<a href="http://openstack.org" target="_blank">openstack.org</a><<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>>> ><br>
>>>>>>>>><br>
>>>>>>>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**</a><br>
>>>>>>> openstack-dev<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>> ______________________________**_________________<br>
>>>>>>><br>
>>>>>>>> OpenStack-dev mailing<br>
>>>>>>>><br>
>>>>>>> list<br>
>>>>>>><br>
>>>>>>>> OpenStack-dev@lists.openstack.**org<<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.">OpenStack-dev@lists.</a>**<a href="http://openstack.org" target="_blank">openstack.org</a><<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>> ><br>
>>>>>>>><br>
>>>>>>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**</a><br>
>>>>>>> openstack-dev<<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> ______________________________**_________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> OpenStack-dev@lists.openstack.**org<<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>>>>><br>
>>>>>> ______________________________**_________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> OpenStack-dev@lists.openstack.**org<<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________**_________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>>><br>
>>> ______________________________**_________________<br>
>>> OpenStack-dev mailing list<br>
>>> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>>><br>
>><br>
>><br>
>> ______________________________**_________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>><br>
><br>
><br>
> ______________________________**_________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/75e55931/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/75e55931/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Thu, 28 Mar 2013 23:22:02 +0200<br>
From: Itzik Brown <<a href="mailto:itzikb@dev.mellanox.co.il">itzikb@dev.mellanox.co.il</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] PCI-passthrough dev ...<br>
Message-ID: <<a href="mailto:5154B47A.6020904@dev.mellanox.co.il">5154B47A.6020904@dev.mellanox.co.il</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
Ian,<br>
<br>
I'm going to send a basic VIF Driver and a config for a network<br>
configuration using macvtap as part of Mellanox Quantum Plugin.<br>
We can schedule an online meeting to discuss some of the key points we<br>
need to address before the summit.<br>
<br>
Itzik<br>
<br>
On 3/28/2013 7:29 PM, Ian Wells wrote:<br>
> Chuck's is not the only summit session:<br>
><br>
> <a href="http://summit.openstack.org/cfp/details/81" target="_blank">http://summit.openstack.org/cfp/details/81</a> (the Quantum side of things<br>
> if you're mapping network devices)<br>
><br>
> ... and I know Mellanox have also been working on that particular side<br>
> of things too. Perhaps we could all get together at the summit before<br>
> the sessions for a show and tell? We could equally work it all out in<br>
> the sessions, but it seems it would be hard to lead a session like<br>
> that without having some knowledge up front of what other people have<br>
> done.<br>
><br>
> To be fair, our code is basically Vladimir Popovski's (Zardara<br>
> Storage's) work, tidied up and with a scheduler check to make sure<br>
> there are actually available SRIOV functions on the node before<br>
> scheduling. It's there, it's actually a patch against Folsom at the<br>
> moment, and it works, but I wouldn't lay claim to it necessarily being<br>
> the One True Way to implement this (and I don't think it has tests<br>
> enough to pass a review).<br>
> --<br>
> Ian.<br>
><br>
><br>
><br>
> On 25 March 2013 16:23, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><br>
> <mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
><br>
> On 03/24/2013 01:44 PM, Ian Wells wrote:<br>
> > Yep, we've got code in test at the moment.<br>
><br>
> This is (at least) the second instance that I've heard of where PCI<br>
> passthrough has been implemented, but code hasn't surfaced yet. It's<br>
> really unfortunate to see the duplication of effort happening.<br>
><br>
> Chuck Short also proposed a design summit session on it, presumably to<br>
> discuss implementing it yet another time:<br>
><br>
> <a href="http://summit.openstack.org/cfp/details/29" target="_blank">http://summit.openstack.org/cfp/details/29</a><br>
><br>
> It would be really nice to get some code out in the open for this.<br>
> :-)<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/4697e3f7/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/4697e3f7/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Thu, 28 Mar 2013 15:14:31 -0700<br>
From: Pattabi Ayyasami <pattabi@Brocade.com><br>
To: "'<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>'<br>
(<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Quantum][LBaaS]- - LBaaS Extension in<br>
Quantum Plugin<br>
Message-ID:<br>
<<a href="mailto:62F41AB0AC0AB541BC3C2A731A7788C60140760E11B1@HQ1-EXCH03.corp.brocade.com">62F41AB0AC0AB541BC3C2A731A7788C60140760E11B1@HQ1-EXCH03.corp.brocade.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
Hi Eugene and All,<br>
<br>
I just happened to notice this email thread in my digest. Sorry for the late query on this.<br>
I am kinda lost on this. Please help me understand.<br>
<br>
<br>
My team is currently working on providing the Brocade LBaaS Driver. We currently have implemented the Driver as per the Driver APIs and installing the patch as per <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> on top of the Quantum Code base and validated the functionality end-to-end using the Quantum CLIs for the LBaaS as per <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI</a>. FYI, our Brocade Load Balancer is currently h/w based.<br>
<br>
Now, I see that <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> review is abandoned. What does it mean now? Driver framework code as suggested by <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> is no longer applicable?<br>
Should we now wait for summit to discuss further on the next steps for the vendors to integrate their drivers?<br>
<br>
Also, I would like to be part of the weekly meetings on LBaaS and where can I find the meeting details?<br>
<br>
Any detailed clarification on where we stand on supporting LBaaS in Quantum for Grizzly and what should the vendors do for the vendor specific drivers would greatly help in planning .<br>
<br>
Thanks.<br>
Pattabi<br>
<br>
=====================================================================<br>
Sure. Let us plan again to make it happen in forth coming releases.<br>
<br>
Thanks<br>
Anand<br>
<br>
On Mar 14, 2013, at 8:30 AM, "Eugene Nikanorov" <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
<br>
Hi Anand,<br>
<br>
Unfortunately support for all kinds of LB devices or even driver framework for such support appeared to be pretty large feature that has put too much reviewing/testing load on quantum's core development team.<br>
So they proposed alternative solution which is much simpler but supports only process-on-host approach.<br>
I think all that we've discussed was not discarded though.<br>
But obviously feature-rich LBaaS implementation is moved to the next release cycle.<br>
<br>
By the way, we've got code that implements initially proposed approach (as described on the wiki) so I hope we'll get it merged in Havana much sooner.<br>
That could allow us to move forward with developing advanced features like service types, routed LB insertion, etc.<br>
<br>
Thanks,<br>
Eugene.<br>
<br>
<br>
<br>
On Thu, Mar 14, 2013 at 7:06 PM, Palanisamy, Anand <<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a><mailto:<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a>>> wrote:<br>
Eugene,<br>
<br>
First of all, I was surprised that we do not have any support for h/w LBs and VIrtual LBs.<br>
<br>
Now, we badly get into Architecture discussion again for addressing all these concerns before we go for the summit.<br>
<br>
Pls let me know suggestions/comments.<br>
<br>
Thanks<br>
Anand<br>
<br>
On Mar 14, 2013, at 7:54 AM, "Eugene Nikanorov" <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
<br>
I'm afraid there's no detailed description for grizzly lbaas architecture right now.<br>
> So, is this similar to current L3_Agent daemon we have in Quantum for Folsom release?<br>
Correct.<br>
<br>
>As well the confusion is like the general Plug-in and Agent architecture [similar to OVS], we have in OS is like Plug-in will be in Controller and Agent has to be on the Compute Node.<br>
Right, lbaas plugin runs within quantum-server, lbaas agent may run on network controller or on some compute node (remember that it must run on one host only)<br>
<br>
>So, when we are trying for Service Insertion, do we need to have same architecture as Plug-in and Agent above or it should be generic in such a way that independent of underlying Hardware/Products, We should be able to bring up services<br>
I'm not sure I understood your question.<br>
Currently quantum's lbaas plugin supports the only type of loadbalancer and it's not customizible via drivers at this point.<br>
<br>
Thanks,<br>
Eugene.<br>
<br>
On Thu, Mar 14, 2013 at 6:09 PM, balaji patnala <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote:<br>
Hi Eugene,<br>
<br>
<br>
>With current lbaas implementation the link that you've provided is not actual as current implementation has adopted different architecture.<br>
<br>
Can you point me to the links for current implementation details.<br>
<br>
<br>
As well the confusion is like the general Plug-in and Agent architecture [similar to OVS], we have in OS is like Plug-in will be in Controller and Agent has to be on the Compute Node.<br>
<br>
So, when we are trying for Service Insertion, do we need to have same architecture as Plug-in and Agent above or it should be generic in such a way that independent of underlying Hardware/Products, We should be able to bring up services.<br>
<br>
>Current implementation only supports haproxy-on-the-host solution so it's not suitable for hardware/VM LBs.<br>
<br>
So, is this similar to current L3_Agent daemon we have in Quantum for Folsom release?<br>
<br>
Thanks,<br>
Balaji.P<br>
<br>
On Thu, Mar 14, 2013 at 5:25 PM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
Hi Balaji,<br>
<br>
With current lbaas implementation the link that you've provided is not actual as current implementation has adopted different architecture.<br>
<br>
> Can you please through some light on the Agent part of the architecture like where exactly the agent will be running like OpenStack Controller Node or OpenStack Compute Node.?<br>
In grizzly, lbaas agent should run on some node - it could be compute node or network controller node.<br>
The only important is that there MUST be only one instance of lbaas agent running.<br>
<br>
Current implementation only supports haproxy-on-the-host solution so it's not suitable for hardware/VM LBs.<br>
Support for such use case is planned in the next release.<br>
<br>
Thanks,<br>
Eugene.<br>
<br>
On Thu, Mar 14, 2013 at 3:46 PM, balaji patnala <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote:<br>
Hi Ilya,<br>
<br>
As described in the document given in the below link:<br>
<br>
<a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a><br>
<br>
Agent part will be running on Compute Node or Controller Node ?.<br>
<br>
I guess it should be on the Controller Node only. As the driver abstraction layer is for choosing the right driver for the device it has to connect like Driver A to the Device Type A. etc. [This approach is for HW device LB]<br>
<br>
If we want to have SW-based-LB like SLB VM, does the above architecture is valid?<br>
<br>
Can you please through some light on the Agent part of the architecture like where exactly the agent will be running like OpenStack Controller Node or OpenStack Compute Node.?<br>
<br>
Thanks in advance.<br>
<br>
Regards,<br>
Balaji.P<br>
<br>
On Thu, Feb 7, 2013 at 8:26 PM, Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a><mailto:<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>> wrote:<br>
Hi Pattabi,<br>
<br>
Code for LBaaS agent and driver API is on review. You may check it from Gerrit topic <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a>. Instructions on how to run the code in DevStack environment are at <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a>. Driver API is documented at <a href="http://wiki.openstack.org/Quantum/LBaaS/DriverAPI" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/DriverAPI</a><br>
<br>
Thanks,<br>
Ilya<br>
<br>
<br>
2013/2/7 Avishay Balderman <<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a><mailto:<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a>>><br>
The basic lbaas driver is not committed yet ? it is under review.<br>
<br>
From: Pattabi Ayyasami [mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a><mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a>>]<br>
Sent: Thursday, February 07, 2013 3:06 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Quantum][LBaaS] - LBaaS Extension in Quantum Plugin<br>
<br>
Hi,<br>
<br>
I am in the process of adding vendor specific plugin implementation for LBaaS as a service. I have my stand alone driver ready and would like to integrate with the framework.<br>
I looked at the latest Git Hub <a href="https://github.com/openstack/quantum" target="_blank">https://github.com/openstack/quantum</a> repository. I do not find any code that allows me to hook my plugin code to the framework.<br>
<br>
Really appreciate if someone could provide me any pointers on how I go about doing it.<br>
<br>
Regards,<br>
Pattabi<br>
<br>
================================================================<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Thu, 28 Mar 2013 15:22:40 -0700<br>
From: Stefano Maffulli <<a href="mailto:stefano@openstack.org">stefano@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Cc: atul jha <<a href="mailto:koolhead17@gmail.com">koolhead17@gmail.com</a>><br>
Subject: Re: [openstack-dev] Future of Launchpad Answers [Community]<br>
Message-ID: <<a href="mailto:5154C2B0.4010707@openstack.org">5154C2B0.4010707@openstack.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 03/27/2013 12:08 AM, Jesse Pretorius wrote:<br>
> Personally I'm in favour of the full import into Ask. That leaves a<br>
> legacy of information to go back on. The voting for the best answer<br>
> isn't entirely necessary in my view - over time the voting will come in<br>
> from people who found the information useful.<br>
<br>
This makes sense indeed. Atul was thinking of copying over 'manually'<br>
the best/most recent ones. I have no idea of what makes more sense, I<br>
guess it depends on the quantity of questions that are worth moving over.<br>
<br>
> On 26 March 2013 17:40, Thierry Carrez wrote:<br>
> That makes it certainly possible to select questions ('Answered' ones ?)<br>
> and import them with all comments, although proper tagging and selection<br>
> of best answer would be missing... requiring some editorial pass<br>
> afterwards.<br>
<br>
Atul: what do you think?<br>
<br>
> Alternatively, we can just keep LP answers going for selected projects<br>
> that made good use of them.<br>
<br>
I advice strongly against this. LP has a pretty bad UI, mandates a LP<br>
login, the product is probably not going to be developed further and<br>
most of all using different tools will split a nascent community of<br>
users now that we're increasing the efforts to strengthen it. Let's move<br>
the good content to Ask and use that.<br>
<br>
/stef<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Thu, 28 Mar 2013 17:28:48 -0500<br>
From: Anne Gentle <<a href="mailto:anne@openstack.org">anne@openstack.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: atul jha <<a href="mailto:koolhead17@gmail.com">koolhead17@gmail.com</a>><br>
Subject: Re: [openstack-dev] Future of Launchpad Answers [Community]<br>
Message-ID:<br>
<<a href="mailto:CAD0KtVFhVw2q8E07jkZzs_O_2SPu-PGX6_pDwPAuREn2Ls32Rg@mail.gmail.com">CAD0KtVFhVw2q8E07jkZzs_O_2SPu-PGX6_pDwPAuREn2Ls32Rg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Mar 28, 2013 at 5:22 PM, Stefano Maffulli <<a href="mailto:stefano@openstack.org">stefano@openstack.org</a>>wrote:<br>
<br>
> On 03/27/2013 12:08 AM, Jesse Pretorius wrote:<br>
><br>
>> Personally I'm in favour of the full import into Ask. That leaves a<br>
>> legacy of information to go back on. The voting for the best answer<br>
>> isn't entirely necessary in my view - over time the voting will come in<br>
>> from people who found the information useful.<br>
>><br>
><br>
> This makes sense indeed. Atul was thinking of copying over 'manually' the<br>
> best/most recent ones. I have no idea of what makes more sense, I guess it<br>
> depends on the quantity of questions that are worth moving over.<br>
><br>
><br>
> On 26 March 2013 17:40, Thierry Carrez wrote:<br>
>> That makes it certainly possible to select questions ('Answered' ones<br>
>> ?)<br>
>> and import them with all comments, although proper tagging and<br>
>> selection<br>
>> of best answer would be missing... requiring some editorial pass<br>
>> afterwards.<br>
>><br>
><br>
> Atul: what do you think?<br>
><br>
><br>
> Alternatively, we can just keep LP answers going for selected projects<br>
>> that made good use of them.<br>
>><br>
><br>
> I advice strongly against this. LP has a pretty bad UI, mandates a LP<br>
> login, the product is probably not going to be developed further and most<br>
> of all using different tools will split a nascent community of users now<br>
> that we're increasing the efforts to strengthen it. Let's move the good<br>
> content to Ask and use that.<br>
><br>
<br>
I'm with Stefano on this item.My vote is for changeover with editorial<br>
pass. Let's a avoid seeing people ask a question about where to post their<br>
question.<br>
<br>
Hopefully that works for you John - so people won't ask to ask, they'll<br>
just ask. :)<br>
Anne<br>
<br>
><br>
> /stef<br>
><br>
><br>
> ______________________________**_________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/92b3819e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130328/92b3819e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Thu, 28 Mar 2013 17:14:50 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Summit Sessions<br>
Message-ID:<br>
<<a href="mailto:CABJepwgf6tVkjAoFVmYK2n%2Bu-yQMgfg4cN56LndVcTJpbjStmw@mail.gmail.com">CABJepwgf6tVkjAoFVmYK2n+u-yQMgfg4cN56LndVcTJpbjStmw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Henry<br>
<br>
Thanks! Sounds great<br>
<br>
2013/3/28 Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>>:<br>
> Hi Nachi,<br>
><br>
> Thanks for bringing this to my attention. My initial reaction is that, yes,<br>
> it should be covered by QoS. I will refer to it in my write-up for the QoS<br>
> proposal, and keep in touch with you for a potential merge.<br>
><br>
> -- Henry<br>
><br>
> On Wed, Mar 27, at 7:56 pm, Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>> wrote:<br>
><br>
>> Hi<br>
>><br>
>> I'm also planning to implement related feature in H.<br>
>> BP <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-control-on-external-gateway" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-control-on-external-gateway</a><br>
>><br>
>> Basically, I wanna stop exhaust of external network connection by one tenant<br>
>><br>
>> May be we can merge our proposals.<br>
>> Your qos api is per port based one?<br>
>><br>
>> Regards<br>
>> Nachi<br>
>><br>
>> 2013/3/27 Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>>:<br>
>>> I will be adding some more details to the proposal soon.<br>
>>><br>
>>> -- Henry<br>
>>><br>
>>> On Wed, Mar 27, at 10:50 am, gong yong sheng <<a href="mailto:gongysh@linux.vnet.ibm.com">gongysh@linux.vnet.ibm.com</a>> wrote:<br>
>>><br>
>>>> It will help if u can have some design before summit discuss.<br>
>>>> On 03/27/2013 10:33 PM, Sean M. Collins wrote:<br>
>>>>> I'd like to get the QoS API proposal in as well.<br>
>>>>><br>
>>>>> <a href="http://summit.openstack.org/cfp/details/160" target="_blank">http://summit.openstack.org/cfp/details/160</a><br>
>>>>><br>
>>>>> I am currently working with Comcast, and this is a must-have feature in<br>
>>>>> Quantum.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 29 Mar 2013 04:24:14 +0100<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum][LBaaS]- - LBaaS Extension in<br>
Quantum Plugin<br>
Message-ID: <<a href="mailto:5155095E.3040604@inaugust.com">5155095E.3040604@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 03/28/2013 11:14 PM, Pattabi Ayyasami wrote:<br>
><br>
> Hi Eugene and All,<br>
><br>
> I just happened to notice this email thread in my digest. Sorry for<br>
> the late query on this. I am kinda lost on this. Please help me<br>
> understand.<br>
><br>
><br>
> My team is currently working on providing the Brocade LBaaS Driver.<br>
> We currently have implemented the Driver as per the Driver APIs and<br>
> installing the patch as per <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> on<br>
> top of the Quantum Code base and validated the functionality<br>
> end-to-end using the Quantum CLIs for the LBaaS as per<br>
> <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI</a>. FYI, our Brocade<br>
> Load Balancer is currently h/w based.<br>
<br>
Awesome! Happy to know that you've done that.<br>
<br>
> Now, I see that <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> review is<br>
> abandoned. What does it mean now? Driver framework code as suggested<br>
> by <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> is no longer applicable?<br>
> Should we now wait for summit to discuss further on the next steps<br>
> for the vendors to integrate their drivers?<br>
<br>
Our system automatically abandons patches with negative reviews after a<br>
week so that we don't keep a lot of cruft around. In this case though,<br>
Dan just put a -2 on the review to prevent it from accidentally getting<br>
merged before we open up development for havana again. As soon as havana<br>
is open, we can restore that patch and work on getting it applied - so<br>
no need to worry!<br>
<br>
> Also, I would like to be part of the weekly meetings on LBaaS and<br>
> where can I find the meeting details?<br>
><br>
> Any detailed clarification on where we stand on supporting LBaaS in<br>
> Quantum for Grizzly and what should the vendors do for the vendor<br>
> specific drivers would greatly help in planning .<br>
><br>
> Thanks. Pattabi<br>
><br>
> =====================================================================<br>
><br>
><br>
Sure. Let us plan again to make it happen in forth coming releases.<br>
><br>
> Thanks Anand<br>
><br>
> On Mar 14, 2013, at 8:30 AM, "Eugene Nikanorov"<br>
> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
><br>
> Hi Anand,<br>
><br>
> Unfortunately support for all kinds of LB devices or even driver<br>
> framework for such support appeared to be pretty large feature that<br>
> has put too much reviewing/testing load on quantum's core development<br>
> team. So they proposed alternative solution which is much simpler but<br>
> supports only process-on-host approach. I think all that we've<br>
> discussed was not discarded though. But obviously feature-rich LBaaS<br>
> implementation is moved to the next release cycle.<br>
><br>
> By the way, we've got code that implements initially proposed<br>
> approach (as described on the wiki) so I hope we'll get it merged in<br>
> Havana much sooner. That could allow us to move forward with<br>
> developing advanced features like service types, routed LB insertion,<br>
> etc.<br>
><br>
> Thanks, Eugene.<br>
><br>
><br>
><br>
> On Thu, Mar 14, 2013 at 7:06 PM, Palanisamy, Anand<br>
> <<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a><mailto:<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a>>> wrote:<br>
> Eugene,<br>
><br>
> First of all, I was surprised that we do not have any support for h/w<br>
> LBs and VIrtual LBs.<br>
><br>
> Now, we badly get into Architecture discussion again for addressing<br>
> all these concerns before we go for the summit.<br>
><br>
> Pls let me know suggestions/comments.<br>
><br>
> Thanks Anand<br>
><br>
> On Mar 14, 2013, at 7:54 AM, "Eugene Nikanorov"<br>
> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
><br>
> I'm afraid there's no detailed description for grizzly lbaas<br>
> architecture right now.<br>
>> So, is this similar to current L3_Agent daemon we have in Quantum<br>
>> for Folsom release?<br>
> Correct.<br>
><br>
>> As well the confusion is like the general Plug-in and Agent<br>
>> architecture [similar to OVS], we have in OS is like Plug-in will<br>
>> be in Controller and Agent has to be on the Compute Node.<br>
> Right, lbaas plugin runs within quantum-server, lbaas agent may run<br>
> on network controller or on some compute node (remember that it must<br>
> run on one host only)<br>
><br>
>> So, when we are trying for Service Insertion, do we need to have<br>
>> same architecture as Plug-in and Agent above or it should be<br>
>> generic in such a way that independent of underlying<br>
>> Hardware/Products, We should be able to bring up services<br>
> I'm not sure I understood your question. Currently quantum's lbaas<br>
> plugin supports the only type of loadbalancer and it's not<br>
> customizible via drivers at this point.<br>
><br>
> Thanks, Eugene.<br>
><br>
> On Thu, Mar 14, 2013 at 6:09 PM, balaji patnala<br>
> <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi<br>
> Eugene,<br>
><br>
><br>
>> With current lbaas implementation the link that you've provided is<br>
>> not actual as current implementation has adopted different<br>
>> architecture.<br>
><br>
> Can you point me to the links for current implementation details.<br>
><br>
><br>
> As well the confusion is like the general Plug-in and Agent<br>
> architecture [similar to OVS], we have in OS is like Plug-in will be<br>
> in Controller and Agent has to be on the Compute Node.<br>
><br>
> So, when we are trying for Service Insertion, do we need to have same<br>
> architecture as Plug-in and Agent above or it should be generic in<br>
> such a way that independent of underlying Hardware/Products, We<br>
> should be able to bring up services.<br>
><br>
>> Current implementation only supports haproxy-on-the-host solution<br>
>> so it's not suitable for hardware/VM LBs.<br>
><br>
> So, is this similar to current L3_Agent daemon we have in Quantum for<br>
> Folsom release?<br>
><br>
> Thanks, Balaji.P<br>
><br>
> On Thu, Mar 14, 2013 at 5:25 PM, Eugene Nikanorov<br>
> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote: Hi<br>
> Balaji,<br>
><br>
> With current lbaas implementation the link that you've provided is<br>
> not actual as current implementation has adopted different<br>
> architecture.<br>
><br>
>> Can you please through some light on the Agent part of the<br>
>> architecture like where exactly the agent will be running like<br>
>> OpenStack Controller Node or OpenStack Compute Node.?<br>
> In grizzly, lbaas agent should run on some node - it could be compute<br>
> node or network controller node. The only important is that there<br>
> MUST be only one instance of lbaas agent running.<br>
><br>
> Current implementation only supports haproxy-on-the-host solution so<br>
> it's not suitable for hardware/VM LBs. Support for such use case is<br>
> planned in the next release.<br>
><br>
> Thanks, Eugene.<br>
><br>
> On Thu, Mar 14, 2013 at 3:46 PM, balaji patnala<br>
> <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi Ilya,<br>
><br>
> As described in the document given in the below link:<br>
><br>
> <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a><br>
><br>
> Agent part will be running on Compute Node or Controller Node ?.<br>
><br>
> I guess it should be on the Controller Node only. As the driver<br>
> abstraction layer is for choosing the right driver for the device it<br>
> has to connect like Driver A to the Device Type A. etc. [This<br>
> approach is for HW device LB]<br>
><br>
> If we want to have SW-based-LB like SLB VM, does the above<br>
> architecture is valid?<br>
><br>
> Can you please through some light on the Agent part of the<br>
> architecture like where exactly the agent will be running like<br>
> OpenStack Controller Node or OpenStack Compute Node.?<br>
><br>
> Thanks in advance.<br>
><br>
> Regards, Balaji.P<br>
><br>
> On Thu, Feb 7, 2013 at 8:26 PM, Ilya Shakhat<br>
> <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a><mailto:<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>> wrote: Hi<br>
> Pattabi,<br>
><br>
> Code for LBaaS agent and driver API is on review. You may check it<br>
> from Gerrit topic <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a>.<br>
> Instructions on how to run the code in DevStack environment are at<br>
> <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a>. Driver API is<br>
> documented at <a href="http://wiki.openstack.org/Quantum/LBaaS/DriverAPI" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/DriverAPI</a><br>
><br>
> Thanks, Ilya<br>
><br>
><br>
> 2013/2/7 Avishay Balderman<br>
> <<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a><mailto:<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a>>> The basic lbaas<br>
> driver is not committed yet ? it is under review.<br>
><br>
> From: Pattabi Ayyasami<br>
> [mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a><mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a>>] Sent:<br>
> Thursday, February 07, 2013 3:06 AM To:<br>
> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
><br>
><br>
Subject: [openstack-dev] [Quantum][LBaaS] - LBaaS Extension in Quantum<br>
Plugin<br>
><br>
> Hi,<br>
><br>
> I am in the process of adding vendor specific plugin implementation<br>
> for LBaaS as a service. I have my stand alone driver ready and would<br>
> like to integrate with the framework. I looked at the latest Git Hub<br>
> <a href="https://github.com/openstack/quantum" target="_blank">https://github.com/openstack/quantum</a> repository. I do not find any<br>
> code that allows me to hook my plugin code to the framework.<br>
><br>
> Really appreciate if someone could provide me any pointers on how I<br>
> go about doing it.<br>
><br>
> Regards, Pattabi<br>
><br>
> ================================================================<br>
><br>
><br>
> _______________________________________________ OpenStack-dev mailing<br>
> list <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 29 Mar 2013 04:25:14 +0100<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [EHO] Project name change [Savanna]<br>
Message-ID: <<a href="mailto:5155099A.8000306@inaugust.com">5155099A.8000306@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 03/22/2013 08:22 PM, Sergey Lukjanov wrote:<br>
> Hi everybody,<br>
><br>
> we have changed our project codename to Savanna (from EHO). Here is our new wiki page - <a href="https://wiki.openstack.org/wiki/Savanna" target="_blank">https://wiki.openstack.org/wiki/Savanna</a> and new site - <a href="http://savanna.mirantis.com" target="_blank">http://savanna.mirantis.com</a>.<br>
><br>
> We decided to do that because of the following reasons:<br>
> * we don't want to violate trademarks usage of Hadoop and OpenStack<br>
> * we think that Savanna sounds much better than EHO for the english speaking audience<br>
> * if Savanna will become an integrated OpenStack project, OpenStack Savanna is much better than OpenStack Elastic Hadoop on OpenStack<br>
> * Savanna is the place where elephants leave :)<br>
<br>
I like elephants!<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 29 Mar 2013 04:30:37 +0100<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [EHO] Project name change [Savanna]<br>
Message-ID: <<a href="mailto:51550ADD.7090403@inaugust.com">51550ADD.7090403@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 03/22/2013 08:22 PM, Sergey Lukjanov wrote:<br>
> Hi everybody,<br>
><br>
> we have changed our project codename to Savanna (from EHO). Here is our new wiki page - <a href="https://wiki.openstack.org/wiki/Savanna" target="_blank">https://wiki.openstack.org/wiki/Savanna</a> and new site - <a href="http://savanna.mirantis.com" target="_blank">http://savanna.mirantis.com</a>.<br>
><br>
> We decided to do that because of the following reasons:<br>
> * we don't want to violate trademarks usage of Hadoop and OpenStack<br>
> * we think that Savanna sounds much better than EHO for the english speaking audience<br>
> * if Savanna will become an integrated OpenStack project, OpenStack Savanna is much better than OpenStack Elastic Hadoop on OpenStack<br>
> * Savanna is the place where elephants leave :)<br>
<br>
Hi!<br>
<br>
I just looked at your wiki page - it's looking good. Have you guys<br>
looked at integrating heat into your provisioning step? It seems like if<br>
you're going to spin up elastic clusters there may be some overlap.<br>
<br>
Also, I don't know if you are aware of it, but the TripleO group has<br>
made a tool in stackforge called diskimage-builder (we're not as good at<br>
names as you are) We've already worked with the reddwarf guys to make it<br>
the basis of the service images they deploy. It seems that since you<br>
deploy images with hadoop pre-installed, a mechanism to describe and<br>
create those images is going to be something you'll need... we'd love to<br>
talk with you about it at some point. Are you going to be a the summit?<br>
<br>
Monty<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Thu, 28 Mar 2013 22:02:02 -0700<br>
From: Samuel Merritt <<a href="mailto:sam@swiftstack.com">sam@swiftstack.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [keystone] naming case sensitive or not?<br>
Message-ID: <<a href="mailto:5155204A.8050703@swiftstack.com">5155204A.8050703@swiftstack.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 3/28/13 8:06 AM, Dolph Mathews wrote:<br>
> That's basically up to the identity driver in use -- for example, with<br>
> the SQL driver, if your database is case sensitive, then keystone will<br>
> be as well.<br>
<br>
That raises an interesting question about authorization with Keystone.<br>
<br>
In Swift, we have container ACLs that are of one of three* forms:<br>
<br>
(A) tenant_name:user_id<br>
(B) tenant_id:user_id<br>
(C) *:user_id<br>
<br>
Form A is the interesting one here. Let's say I have a container on<br>
which I have set a read ACL of "CamelCorp:12345". Then, a request comes<br>
in, and when Swift's keystoneauth middleware** gets called, it sees that<br>
the tenant name retrieved from Keystone is "Camelcorp" (different<br>
case!), and the user id is 12345 (a match).<br>
<br>
Should that request be allowed or not?<br>
<br>
<br>
* okay, there's the .r: stuff for referrer-based ACLs, but that's not<br>
germane to this discussion<br>
<br>
** swift.common.middleware.keystoneauth.KeystoneAuth, for those who wish<br>
to read the code<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Fri, 29 Mar 2013 10:10:13 +0400<br>
From: Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum][LBaaS]- - LBaaS Extension in<br>
Quantum Plugin<br>
Message-ID:<br>
<CAJfiwOSOCFbgagQAwk6WC5BpxBheOACfrwt_-ur-Mo=<a href="mailto:GKZfYng@mail.gmail.com">GKZfYng@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi, Pattabi,<br>
<br>
Yes, it's better to wait for the summit prior to implementing device<br>
drivers.<br>
It's seems that there will be two major approaches competing, which<br>
probably would require different versions of lbaas plugin.<br>
<br>
Currently regular lbaas meetings are not held.<br>
I think it will change after the summit as the direction for the further<br>
service development will be set.<br>
<br>
*> Any detailed clarification on where we stand on supporting LBaaS in<br>
Quantum for Grizzly and what should the vendors do for the vendor specific<br>
drivers would greatly help in planning.*<br>
Current "reference implementation" is focused on HAProxy and does not<br>
directly support pluggable device drivers.<br>
In theory, vendor could implement it's device-specific agent the same way<br>
it's implemented for HAProxy, but i think it's better to wait until<br>
pluggable drivers support is introduced. All these design questions will be<br>
discussed at summit.<br>
<br>
Thanks,<br>
Eugene.<br>
<br>
On Fri, Mar 29, 2013 at 7:24 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
<br>
> On 03/28/2013 11:14 PM, Pattabi Ayyasami wrote:<br>
> ><br>
> > Hi Eugene and All,<br>
> ><br>
> > I just happened to notice this email thread in my digest. Sorry for<br>
> > the late query on this. I am kinda lost on this. Please help me<br>
> > understand.<br>
> ><br>
> ><br>
> > My team is currently working on providing the Brocade LBaaS Driver.<br>
> > We currently have implemented the Driver as per the Driver APIs and<br>
> > installing the patch as per <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> on<br>
> > top of the Quantum Code base and validated the functionality<br>
> > end-to-end using the Quantum CLIs for the LBaaS as per<br>
> > <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI</a>. FYI, our Brocade<br>
> > Load Balancer is currently h/w based.<br>
><br>
> Awesome! Happy to know that you've done that.<br>
><br>
> > Now, I see that <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> review is<br>
> > abandoned. What does it mean now? Driver framework code as suggested<br>
> > by <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> is no longer applicable?<br>
> > Should we now wait for summit to discuss further on the next steps<br>
> > for the vendors to integrate their drivers?<br>
><br>
> Our system automatically abandons patches with negative reviews after a<br>
> week so that we don't keep a lot of cruft around. In this case though,<br>
> Dan just put a -2 on the review to prevent it from accidentally getting<br>
> merged before we open up development for havana again. As soon as havana<br>
> is open, we can restore that patch and work on getting it applied - so<br>
> no need to worry!<br>
><br>
> > Also, I would like to be part of the weekly meetings on LBaaS and<br>
> > where can I find the meeting details?<br>
> ><br>
> > Any detailed clarification on where we stand on supporting LBaaS in<br>
> > Quantum for Grizzly and what should the vendors do for the vendor<br>
> > specific drivers would greatly help in planning .<br>
> ><br>
> > Thanks. Pattabi<br>
> ><br>
> > =====================================================================<br>
> ><br>
> ><br>
> Sure. Let us plan again to make it happen in forth coming releases.<br>
> ><br>
> > Thanks Anand<br>
> ><br>
> > On Mar 14, 2013, at 8:30 AM, "Eugene Nikanorov"<br>
> > <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
> ><br>
> > Hi Anand,<br>
> ><br>
> > Unfortunately support for all kinds of LB devices or even driver<br>
> > framework for such support appeared to be pretty large feature that<br>
> > has put too much reviewing/testing load on quantum's core development<br>
> > team. So they proposed alternative solution which is much simpler but<br>
> > supports only process-on-host approach. I think all that we've<br>
> > discussed was not discarded though. But obviously feature-rich LBaaS<br>
> > implementation is moved to the next release cycle.<br>
> ><br>
> > By the way, we've got code that implements initially proposed<br>
> > approach (as described on the wiki) so I hope we'll get it merged in<br>
> > Havana much sooner. That could allow us to move forward with<br>
> > developing advanced features like service types, routed LB insertion,<br>
> > etc.<br>
> ><br>
> > Thanks, Eugene.<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Mar 14, 2013 at 7:06 PM, Palanisamy, Anand<br>
> > <<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a><mailto:<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a>>> wrote:<br>
> > Eugene,<br>
> ><br>
> > First of all, I was surprised that we do not have any support for h/w<br>
> > LBs and VIrtual LBs.<br>
> ><br>
> > Now, we badly get into Architecture discussion again for addressing<br>
> > all these concerns before we go for the summit.<br>
> ><br>
> > Pls let me know suggestions/comments.<br>
> ><br>
> > Thanks Anand<br>
> ><br>
> > On Mar 14, 2013, at 7:54 AM, "Eugene Nikanorov"<br>
> > <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>
> ><br>
> > I'm afraid there's no detailed description for grizzly lbaas<br>
> > architecture right now.<br>
> >> So, is this similar to current L3_Agent daemon we have in Quantum<br>
> >> for Folsom release?<br>
> > Correct.<br>
> ><br>
> >> As well the confusion is like the general Plug-in and Agent<br>
> >> architecture [similar to OVS], we have in OS is like Plug-in will<br>
> >> be in Controller and Agent has to be on the Compute Node.<br>
> > Right, lbaas plugin runs within quantum-server, lbaas agent may run<br>
> > on network controller or on some compute node (remember that it must<br>
> > run on one host only)<br>
> ><br>
> >> So, when we are trying for Service Insertion, do we need to have<br>
> >> same architecture as Plug-in and Agent above or it should be<br>
> >> generic in such a way that independent of underlying<br>
> >> Hardware/Products, We should be able to bring up services<br>
> > I'm not sure I understood your question. Currently quantum's lbaas<br>
> > plugin supports the only type of loadbalancer and it's not<br>
> > customizible via drivers at this point.<br>
> ><br>
> > Thanks, Eugene.<br>
> ><br>
> > On Thu, Mar 14, 2013 at 6:09 PM, balaji patnala<br>
> > <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi<br>
> > Eugene,<br>
> ><br>
> ><br>
> >> With current lbaas implementation the link that you've provided is<br>
> >> not actual as current implementation has adopted different<br>
> >> architecture.<br>
> ><br>
> > Can you point me to the links for current implementation details.<br>
> ><br>
> ><br>
> > As well the confusion is like the general Plug-in and Agent<br>
> > architecture [similar to OVS], we have in OS is like Plug-in will be<br>
> > in Controller and Agent has to be on the Compute Node.<br>
> ><br>
> > So, when we are trying for Service Insertion, do we need to have same<br>
> > architecture as Plug-in and Agent above or it should be generic in<br>
> > such a way that independent of underlying Hardware/Products, We<br>
> > should be able to bring up services.<br>
> ><br>
> >> Current implementation only supports haproxy-on-the-host solution<br>
> >> so it's not suitable for hardware/VM LBs.<br>
> ><br>
> > So, is this similar to current L3_Agent daemon we have in Quantum for<br>
> > Folsom release?<br>
> ><br>
> > Thanks, Balaji.P<br>
> ><br>
> > On Thu, Mar 14, 2013 at 5:25 PM, Eugene Nikanorov<br>
> > <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote: Hi<br>
> > Balaji,<br>
> ><br>
> > With current lbaas implementation the link that you've provided is<br>
> > not actual as current implementation has adopted different<br>
> > architecture.<br>
> ><br>
> >> Can you please through some light on the Agent part of the<br>
> >> architecture like where exactly the agent will be running like<br>
> >> OpenStack Controller Node or OpenStack Compute Node.?<br>
> > In grizzly, lbaas agent should run on some node - it could be compute<br>
> > node or network controller node. The only important is that there<br>
> > MUST be only one instance of lbaas agent running.<br>
> ><br>
> > Current implementation only supports haproxy-on-the-host solution so<br>
> > it's not suitable for hardware/VM LBs. Support for such use case is<br>
> > planned in the next release.<br>
> ><br>
> > Thanks, Eugene.<br>
> ><br>
> > On Thu, Mar 14, 2013 at 3:46 PM, balaji patnala<br>
> > <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi Ilya,<br>
> ><br>
> > As described in the document given in the below link:<br>
> ><br>
> > <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a><br>
> ><br>
> > Agent part will be running on Compute Node or Controller Node ?.<br>
> ><br>
> > I guess it should be on the Controller Node only. As the driver<br>
> > abstraction layer is for choosing the right driver for the device it<br>
> > has to connect like Driver A to the Device Type A. etc. [This<br>
> > approach is for HW device LB]<br>
> ><br>
> > If we want to have SW-based-LB like SLB VM, does the above<br>
> > architecture is valid?<br>
> ><br>
> > Can you please through some light on the Agent part of the<br>
> > architecture like where exactly the agent will be running like<br>
> > OpenStack Controller Node or OpenStack Compute Node.?<br>
> ><br>
> > Thanks in advance.<br>
> ><br>
> > Regards, Balaji.P<br>
> ><br>
> > On Thu, Feb 7, 2013 at 8:26 PM, Ilya Shakhat<br>
> > <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a><mailto:<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>> wrote: Hi<br>
> > Pattabi,<br>
> ><br>
> > Code for LBaaS agent and driver API is on review. You may check it<br>
> > from Gerrit topic <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a>.<br>
> > Instructions on how to run the code in DevStack environment are at<br>
> > <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a>. Driver API is<br>
> > documented at <a href="http://wiki.openstack.org/Quantum/LBaaS/DriverAPI" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/DriverAPI</a><br>
> ><br>
> > Thanks, Ilya<br>
> ><br>
> ><br>
> > 2013/2/7 Avishay Balderman<br>
> > <<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a><mailto:<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a>>> The basic lbaas<br>
> > driver is not committed yet ? it is under review.<br>
> ><br>
> > From: Pattabi Ayyasami<br>
> > [mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a><mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a>>] Sent:<br>
> > Thursday, February 07, 2013 3:06 AM To:<br>
> > <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<br>
> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> ><br>
> ><br>
> Subject: [openstack-dev] [Quantum][LBaaS] - LBaaS Extension in Quantum<br>
> Plugin<br>
> ><br>
> > Hi,<br>
> ><br>
> > I am in the process of adding vendor specific plugin implementation<br>
> > for LBaaS as a service. I have my stand alone driver ready and would<br>
> > like to integrate with the framework. I looked at the latest Git Hub<br>
> > <a href="https://github.com/openstack/quantum" target="_blank">https://github.com/openstack/quantum</a> repository. I do not find any<br>
> > code that allows me to hook my plugin code to the framework.<br>
> ><br>
> > Really appreciate if someone could provide me any pointers on how I<br>
> > go about doing it.<br>
> ><br>
> > Regards, Pattabi<br>
> ><br>
> > ================================================================<br>
> ><br>
> ><br>
> > _______________________________________________ OpenStack-dev mailing<br>
> > list <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/e7b8ba8d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/e7b8ba8d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Fri, 29 Mar 2013 12:30:09 +0530<br>
From: balaji patnala <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Ilya Shakhat<br>
<<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>><br>
Subject: Re: [openstack-dev] [Doc][LBaaS] API doc for LBaaS extension<br>
is ready for review<br>
Message-ID:<br>
<<a href="mailto:CANT02KRnZzhqLaTZvPZKBdoWMVaYQLmxZbwituArdoEK8hKtuw@mail.gmail.com">CANT02KRnZzhqLaTZvPZKBdoWMVaYQLmxZbwituArdoEK8hKtuw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Ilya,<br>
<br>
Do we have any blue-print for this. Just want to understand the<br>
architecture we followed for this.<br>
<br>
As this feature has got into multiple discussions and architecture changes.<br>
<br>
we should understand the basic architecture so that we can extend the same<br>
for both HW based SLBs and VM based SLBs.<br>
<br>
Regards,<br>
Balaji.P<br>
<br>
On Thu, Mar 28, 2013 at 5:43 PM, Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Please review a new section in API docs describing LBaaS extension. Review<br>
> is <a href="https://review.openstack.org/#/c/25409/" target="_blank">https://review.openstack.org/#/c/25409/</a><br>
> The text is partially based on<br>
> <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0</a> . Requests and<br>
> responses are captured from traffic between python-client and quantum, thus<br>
> may slightly differ from what documented on wiki.<br>
><br>
> Thanks,<br>
> Ilya<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/51e8c860/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/51e8c860/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Fri, 29 Mar 2013 13:03:00 +0400<br>
From: Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>><br>
To: balaji patnala <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Doc][LBaaS] API doc for LBaaS extension<br>
is ready for review<br>
Message-ID:<br>
<CAMzOD1JacgCijiaoUTNnzGz3cfiNZq9MAoG1=dH_X2=-<a href="mailto:13jyRA@mail.gmail.com">13jyRA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Balaji,<br>
<br>
There are 3 blueprints directly related to LBaaS:<br>
* <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant" target="_blank">https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant</a> -<br>
REST API as it is specified at<br>
<a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0</a><br>
* <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-plugin-api-crud" target="_blank">https://blueprints.launchpad.net/quantum/+spec/lbaas-plugin-api-crud</a> -<br>
db and plugin<br>
* <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-namespace-agent" target="_blank">https://blueprints.launchpad.net/quantum/+spec/lbaas-namespace-agent</a> -<br>
agent and driver for HAProxy<br>
<br>
The agent part is less documented, but its designed similar to L3 and DHCP<br>
agents. The agent polls LB plugin via RPC and retrieves the full<br>
configuration. If there are changes (new objects in PENDING_CREATE state,<br>
or updated in PENDING_UPDATE) they are applied to HAProxy. Every pool/vip<br>
results in 1 haproxy process running on the same host as agent. Haproxy is<br>
executed in separate IP namespace, thus all load balancers isolated from<br>
each other from OS and network perspectives. There is exactly 1 haproxy per<br>
pool/vip.<br>
<br>
The roadmap for LB plugin is vast and will be discussed at the Summit.<br>
Current proposals are at <a href="https://etherpad.openstack.org/havana-quantum-lbaas" target="_blank">https://etherpad.openstack.org/havana-quantum-lbaas</a><br>
.<br>
<br>
<br>
Thanks,<br>
Ilya<br>
<br>
2013/3/29 balaji patnala <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>><br>
<br>
> Hi Ilya,<br>
><br>
> Do we have any blue-print for this. Just want to understand the<br>
> architecture we followed for this.<br>
><br>
> As this feature has got into multiple discussions and architecture changes.<br>
><br>
> we should understand the basic architecture so that we can extend the same<br>
> for both HW based SLBs and VM based SLBs.<br>
><br>
> Regards,<br>
> Balaji.P<br>
><br>
> On Thu, Mar 28, 2013 at 5:43 PM, Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>wrote:<br>
><br>
>> Hi,<br>
>><br>
>> Please review a new section in API docs describing LBaaS extension.<br>
>> Review is <a href="https://review.openstack.org/#/c/25409/" target="_blank">https://review.openstack.org/#/c/25409/</a><br>
>> The text is partially based on<br>
>> <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/API_1.0</a> . Requests and<br>
>> responses are captured from traffic between python-client and quantum, thus<br>
>> may slightly differ from what documented on wiki.<br>
>><br>
>> Thanks,<br>
>> Ilya<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/5c876e4a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/5c876e4a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Fri, 29 Mar 2013 10:34:24 +0100<br>
From: Chmouel Boudjnah <<a href="mailto:chmouel@chmouel.com">chmouel@chmouel.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Fwd: [keystone] Keystone handling http<br>
requests synchronously<br>
Message-ID:<br>
<<a href="mailto:CAPeWyqy5qVwCZAs1jLUxqAYpcCHOpwmekwyNXVCprTJSFUUttA@mail.gmail.com">CAPeWyqy5qVwCZAs1jLUxqAYpcCHOpwmekwyNXVCprTJSFUUttA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
FYI<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>><br>
Date: Thu, Mar 28, 2013 at 10:04 PM<br>
Subject: Re: [openstack-dev] [keystone] Keystone handling http<br>
requests synchronously<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
<br>
On 03/26/2013 01:34 PM, David Kranz wrote:<br>
><br>
> This is without memcache in auth_token. I was trying to find a way past <a href="https://bugs.launchpad.net/keystone/+bug/1020127" target="_blank">https://bugs.launchpad.net/keystone/+bug/1020127</a><br>
> which I think I now have. I would appreciate it if you could validate my comment at the end of that ticket. Here, I just thought that the keystone<br>
> throughput was very low. I know that swift should not be hitting it so hard. If you were referring to using memcache in the keystone server itself then<br>
<br>
You can use memcached as an alternate token back end, but I have no<br>
reason to thin it would perform any better than SQL. It was broken<br>
until fairly recently, too, so I suspect it is not used much in the<br>
wild.<br>
<br>
<br>
<br>
> I didn't know you could do that.<br>
><br>
> -David<br>
><br>
><br>
><br>
> On 3/26/2013 12:33 PM, Chmouel Boudjnah wrote:<br>
>><br>
>> this seems to be pretty low, do you have memcaching enabled?<br>
>><br>
>> On Tue, Mar 26, 2013 at 4:20 PM, David Kranz <<a href="mailto:david.kranz@qrclab.com">david.kranz@qrclab.com</a>> wrote:<br>
>>><br>
>>> Related to this, I measured that the rate at which keystone (running on a<br>
>>> real fairly hefty server) can handle the requests coming from the auth_token<br>
>>> middleware (no pki tokens) is about 16/s. That seems pretty low to me. Is<br>
>>> there some other keystone performance problem here, or is that not<br>
>>> surprising?<br>
>>><br>
>>> -David<br>
>>><br>
>>><br>
>>> On 3/24/2013 9:11 PM, Jay Pipes wrote:<br>
>>>><br>
>>>> Sure, you could do that, of course. Just like you could use gunicorn or<br>
>>>> some other web server. Just like you could deploy any of the other<br>
>>>> OpenStack services that way.<br>
>>>><br>
>>>> It would just be nice if one could configure Keystone in the same manner<br>
>>>> that all the other OpenStack services are configured.<br>
>>>><br>
>>>> -jay<br>
>>>><br>
>>>> On 03/23/2013 01:19 PM, Joshua Harlow wrote:<br>
>>>>><br>
>>>>> See: <a href="https://github.com/openstack/keystone/tree/master/httpd" target="_blank">https://github.com/openstack/keystone/tree/master/httpd</a><br>
>>>>><br>
>>>>> For example...<br>
>>>>><br>
>>>>> This lets apache do the multiprocess instead of how nova, glance ...<br>
>>>>> have basically recreated the same mechanism that apache has had for<br>
>>>>> years.<br>
>>>>><br>
>>>>> Sent from my really tiny device...<br>
>>>>><br>
>>>>> On Mar 23, 2013, at 10:14 AM, "Joshua Harlow" <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a><br>
>>>>> <mailto:<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>>> wrote:<br>
>>>>><br>
>>>>>> Or I think u can run keystone in wsgi+apache easily, thus getting u the<br>
>>>>>> multiprocess support via apache worker processes.<br>
>>>>>><br>
>>>>>> Sent from my really tiny<br>
>>>>>> device....<br>
>>>>>><br>
>>>>>> On Mar 22, 2013, at 10:47 AM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
>>>>>> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>>> Unfortunately, Keystone's WSGI server is only a single process,<br>
>>>>>><br>
>>>>>> with a<br>
>>>>>>><br>
>>>>>>> greenthread pool. Unlike Glance, Nova, Cinder, and Swift, which all<br>
>>>>>><br>
>>>>>> use<br>
>>>>>>><br>
>>>>>>> multi-process, greenthread-pool-per-process WSGI servers[1],<br>
>>>>>><br>
>>>>>> Keystone<br>
>>>>>>><br>
>>>>>>> does it differently[2].<br>
>>>>>>><br>
>>>>>>> There was a patchset[3] that added<br>
>>>>>><br>
>>>>>> multiprocess support to Keystone, but<br>
>>>>>>><br>
>>>>>>> due to objections from termie and<br>
>>>>>><br>
>>>>>> others about it not being necessary,<br>
>>>>>>><br>
>>>>>>> it died on the vine. Termie even<br>
>>>>>><br>
>>>>>> noted that Keystone "was designed to be<br>
>>>>>>><br>
>>>>>>> run as multiple instances and load<br>
>>>>>><br>
>>>>>> balanced over and [he felt] that<br>
>>>>>>><br>
>>>>>>> should be the preferred scaling point".<br>
>>>>>>><br>
>>>>>>> Because the mysql client connection is C-based, calls to it will be<br>
>>>>>>><br>
>>>>>> blocking operations on greenthreads within a single process, meaning<br>
>>>>>>><br>
>>>>>>> even<br>
>>>>>><br>
>>>>>> if multiple greenthreads are spawned for those 200 incoming<br>
>>>>>>><br>
>>>>>>> requests, they<br>
>>>>>><br>
>>>>>> will be processed synchronously.<br>
>>>>>>><br>
>>>>>>> The solution is for Keystone to<br>
>>>>>><br>
>>>>>> implement the same multi-processed WSGI<br>
>>>>>>><br>
>>>>>>> worker stuff that is in the other<br>
>>>>>><br>
>>>>>> OpenStack projects. Or, diverge from<br>
>>>>>>><br>
>>>>>>> the deployment solution of Nova,<br>
>>>>>><br>
>>>>>> Glance, Cinder, and Swift, and manually<br>
>>>>>>><br>
>>>>>>> run multiple instances of<br>
>>>>>><br>
>>>>>> keystone, as Termie suggests.<br>
>>>>>>><br>
>>>>>>> Best,<br>
>>>>>>> -jay<br>
>>>>>>><br>
>>>>>>> [1] All pretty much<br>
>>>>>><br>
>>>>>> derived from the original Swift code, with some Oslo<br>
>>>>>>><br>
>>>>>>> improvements around<br>
>>>>>><br>
>>>>>> config<br>
>>>>>>><br>
>>>>>>> [2] Compare<br>
>>>>>>><br>
>>>>>> <a href="https://github.com/openstack/glance/blob/master/glance/common/wsgi.py" target="_blank">https://github.com/openstack/glance/blob/master/glance/common/wsgi.py</a><br>
>>>>>> with<br>
>>>>>><br>
>>>>>> <a href="https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py</a><br>
>>>>>> [3] <a href="https://review.openstack.org/#/c/7017/" target="_blank">https://review.openstack.org/#/c/7017/</a><br>
>>>>>>><br>
>>>>>>> On 03/21/2013 07:45 AM,<br>
>>>>>><br>
>>>>>> Kanade, Rohan wrote:<br>
>>>>>>>><br>
>>>>>>>> Hi,<br>
>>>>>>>><br>
>>>>>>>> I was trying to create 200 users using<br>
>>>>>><br>
>>>>>> the keystone client. All the<br>
>>>>>>>><br>
>>>>>>>> users are unique and are created on separate<br>
>>>>>><br>
>>>>>> threads which are started<br>
>>>>>>>><br>
>>>>>>>> at the same time.<br>
>>>>>>>><br>
>>>>>>>> keystone is handling<br>
>>>>>><br>
>>>>>> each request synchronously , i.e. user 1 is<br>
>>>>>>>><br>
>>>>>>>> created, then user 2 is<br>
>>>>>><br>
>>>>>> created ...<br>
>>>>>>>><br>
>>>>>>>> Shouldnt keystone be running a greenthread for each<br>
>>>>>><br>
>>>>>> request and try to<br>
>>>>>>>><br>
>>>>>>>> create these users asynchronously?<br>
>>>>>>>> like start<br>
>>>>>><br>
>>>>>> creating user 1 , while handling that request, start creating<br>
>>>>>>>><br>
>>>>>>>> user 2 or<br>
>>>>>><br>
>>>>>> user n...<br>
>>>>>>>><br>
>>>>>>>> I have attached the keystone service logs for further<br>
>>>>>><br>
>>>>>> assistance.<br>
>>>>>>>><br>
>>>>>>>> <a href="http://paste.openstack.org/show/34216/" target="_blank">http://paste.openstack.org/show/34216/</a><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> Disclaimer:This email and any attachments are sent in strictest<br>
>>>>>> confidence for the sole use of the addressee and may contain legally<br>
>>>>>> privileged, confidential, and proprietary data. If you are not the<br>
>>>>>> intended recipient, please advise the sender by replying promptly to<br>
>>>>>>>><br>
>>>>>>>> this<br>
>>>>>><br>
>>>>>> email and then delete and destroy this email and any attachments<br>
>>>>>>>><br>
>>>>>>>> without<br>
>>>>>><br>
>>>>>> any further use, copying or forwarding<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>>>><br>
>>>>>>>> OpenStack-dev mailing<br>
>>>>>><br>
>>>>>> list<br>
>>>>>>>><br>
>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>>><br>
>>>>>>> OpenStack-dev mailing<br>
>>>>>><br>
>>>>>> list<br>
>>>>>>><br>
>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>>>>>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Fri, 29 Mar 2013 11:51:23 +0100<br>
From: "Paul Sarin-Pollet" <<a href="mailto:psarpol@gmx.com">psarpol@gmx.com</a>><br>
To: "OpenStack Development Mailing List"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Supporting KMIP in Key Manager<br>
Message-ID: <<a href="mailto:20130329105123.93160@gmx.com">20130329105123.93160@gmx.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi<br>
<br>
Malini, I saw your design summit about KMIP.<br>
Do you know a good opensource implementation of KMIP server ?<br>
The main issue will be for the validation process...<br>
<br>
Thanks<br>
<br>
Paul<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/4014b838/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/4014b838/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 11, Issue 34<br>
*********************************************<br>
</blockquote></div><br></div></div></div>