Re: [Openstack] HTTP headers are incorrectly treated case sensitive by jClouds causing OpenStack x-storage-url to fail
As far as I know, Apache will make it lower-case. I use keystone with Apache frontend (mo-wsgi) and all the headers are in lowercase. I was wondering how David is getting correct case. BTW my environment is Ubuntu Precise running apache2.2 Thanks Haneef From: Openstack [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net] On Behalf Of Ali, Saqib Sent: Friday, June 28, 2013 1:53 PM To: David Hadas Cc: Chmouel Boudjnah; Openstack; openstack@lists.launchpad.net Subject: Re: [Openstack] HTTP headers are incorrectly treated case sensitive by jClouds causing OpenStack x-storage-url to fail Hello David, Thanks for the response. I believe we are using the apache web frontend for the enabling SSL on the end-points. I have asked our OpenStack folks to share the setup and reasoning behind use of the Apache web frontend. They will respond here shortly. I am not sure why our instance of Apache web frontend is returning lower case X-Storage-Url. When we connect directly to the proxy, the X-Storage-Url are correct case. But the Apache frontend somehow makes it all lower case. Would it possible for you to share the relevant Apache config and other setup details for the setup that you have? Thanks. On Fri, Jun 28, 2013 at 9:38 AM, David Hadas dav...@il.ibm.commailto:dav...@il.ibm.com wrote: Ali hi, On my system I get the headers as X-Storage-Url when running under Apache2 front end (not lowercase). Btw, I am always interested to learn how people are using Swift with the Apache front end as this is a fairly recent addition (we are working not to get it into devstack), can you describe shortly your setup and the reason behind choosing Apache front end? DH Regards, David Hadas, Openstack Swift ATC, Architect, Master Inventor IBM Research Labs, Haifa Tel:Int+972-4-829-6104tel:%2B972-4-829-6104 Fax: Int+972-4-829-6112tel:%2B972-4-829-6112 From: Ali, Saqib docbook@gmail.commailto:docbook@gmail.com To: Chmouel Boudjnah chmo...@enovance.commailto:chmo...@enovance.com, Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Date: 28/06/2013 04:30 PM Subject:Re: [Openstack] HTTP headers are incorrectly treated case sensitive by jClouds causing OpenStack x-storage-url to fail Sent by:Openstack openstack-bounces +davidh=il.ibm@lists.launchpad.netmailto:il.ibm@lists.launchpad.net Chmouel, Not really a hack on the swift, just the apache web frontend[1] 1. http://docs.openstack.org/developer/swift/apache_deployment_guide.html On Fri, Jun 28, 2013 at 6:26 AM, Chmouel Boudjnah chmo...@enovance.commailto:chmo...@enovance.com wrote: On Fri, Jun 28, 2013 at 2:00 AM, Ali, Saqib docbook@gmail.commailto:docbook@gmail.com wrote: Is there anything we can do to work around this, while someone from the jClouds community fixes this issue? I would be believe a jclouds fix would be faster to get in than to try agree on a hack to do on swift. Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [keystone] Why are we returing such a big payload in validate token?
Hi, As of now v3 validateToken response has tokens, service catalog, users, project , roles and domains. (i.e) Except for groups we are returning everything. We also discussed about the possibility of 100s of endpoints. ValidateToken is supposed to be a high frequency call .This is going to be a huge performance impact . What is the use case for such a big payload when compared with v2? If a service needs catalog , then the service can always ask for the catalog. Thanks Haneef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
Isn't signed token an optional feature? If so validateToken is going to be a high frequency call. Also Service Catalog is a constant, the services can cache it. It doesn't need to be part of validateToken. Thanks Haneef From: openstack-bounces+haneef.ali=hp@lists.launchpad.net [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Thursday, January 31, 2013 6:25 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] Why are we returing such a big payload in validate token? On 01/31/2013 07:44 PM, Ali, Haneef wrote: Hi, As of now v3 validateToken response has tokens, service catalog, users, project , roles and domains. (i.e) Except for groups we are returning everything. We also discussed about the possibility of 100s of endpoints. ValidateToken is supposed to be a high frequency call .This is Validate token should not going be a high frequency call. The information is encapsulated inside the signed token for just that reason. I would agree with the sentiment, however, that we are cramming a lot of info into the token. TOkens should be scoped much, much more finely: by default one service or endpoint, and one tenant. The only thing that should require the full service catalog is the initial request of an unsigned token, and that should merely go back to the client. going to be a huge performance impact . What is the use case for such a big payload when compared with v2? If a service needs catalog , then the service can always ask for the catalog. Thanks Haneef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Do we have any schema for keystone v3.0 request/responses
Hi, Do we have any XSD file for keystone v3.0 api? All the examples show only json format. I don't see even a single request/response example using xml. Does keystone v3.0 support xml content-type? If so what is the namespace for the v3.0 schema? Thanks Haneef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
