We recently merged an implementation for GET /v3/catalog which finally enables POST /v3/auth/tokens?nocatalog to be a reasonable default behavior, at the cost of an extra HTTP call from remote service back to keystone where necessary.
Spec: https://github.com/openstack/keystone-specs/blob/master/specs/juno/get-catalog.rst Blueprint: https://blueprints.launchpad.net/keystone/+spec/get-catalog API change: https://review.openstack.org/#/c/106854/1/v3/src/markdown/identity-api-v3.md Implementation: https://review.openstack.org/#/c/106893/ I also filed wishlist bug 1350000 ("UUID is a more friendly default token provider than PKI") recently, based on the developer community's recent discussions, which Morgan has subsequently raised to the the mailing list with a survey. Bug: https://bugs.launchpad.net/keystone/+bug/1350000 Corresponding change of defaults: https://review.openstack.org/#/c/110488/ Survey on the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041474.html On Tue, Jul 22, 2014 at 4:04 AM, Giuseppe Galeota <[email protected] > wrote: > > Dear all, > have you some good news about the problem related to > the " > Keystone PKI token too much long" for Barbican? > > Thank you, > Giuseppe > > > > 2014-01-31 14:27 GMT+01:00 Ferreira, Rafael <[email protected]>: > >> By the way, you can achieve the same benefits of uuid tokens (shorter >> tokens) with PKI by simply using a md5 hash of the PKI token for your >> X-Auth headers. This is poorly documented but it seems to work just fine. >> >> From: Adam Young <[email protected]> >> Date: Tuesday, January 28, 2014 at 1:41 PM >> To: "[email protected]" <[email protected]> >> Subject: Re: [Openstack] [Barbican] Keystone PKI token too much long >> >> On 01/22/2014 12:21 PM, John Wood wrote: >> >> (Adding another member of our team Douglas) >> >> Hello Giuseppe, >> >> For questions about news or patches for Keystone's PKI vs UUID modes, >> you might reach out to the [email protected] mailing >> list, with the subject line prefixed with [openstack-dev] [keystone] >> >> Our observation has been that the PKI mode can generate large text >> blocks for tokens (esp. for large service catalogs) that cause http header >> errors. >> >> Regarding the specific barbican scripts you are running, we haven't run >> those in a while, so I'll investigate as we might need to update them. >> Please email back your /etc/barbican/barbican-api-paste.ini paste config >> file when you have a chance as well. >> >> Thanks, >> John >> >> >> ------------------------------ >> *From:* Giuseppe Galeota [[email protected]] >> *Sent:* Wednesday, January 22, 2014 7:36 AM >> *To:* [email protected] >> *Cc:* John Wood >> *Subject:* [Openstack] [Barbican] >> >> Keystone PKI token too much long >> >> Dear all, >> I have configured Keystone for Barbican using this guide >> <https://github.com/cloudkeep/barbican/wiki/Developer-Guide-for-Keystone> >> . >> >> Is there any news or patch about the need to use a shorter token? I >> would not use a modified token. >> >> Its a known problem. You can request a token without the service catalog >> using an extension. >> >> One possible future enhancement is to compress the key. >> >> >> >> Following you can find an extract of the linked guide: >> >> - (Optional) Typical keystone setup creates PKI tokens that are long, >> do not fit easily into curl requests without splitting into components. >> For >> testing purposes suggest updating the keystone database with a shorter >> token-id. (An alternative is to set up keystone to generate uuid tokens.) >> From the above output grad the token expiry value, referred to as "x-y-z" >> >> mysql -u rootuse keystone;update token set id="foo" where expires="x-y-z" ; >> >> >> Thank you, >> Giuseppe >> >> >> _______________________________________________ >> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : [email protected] >> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> >> The communication contained in this e-mail is confidential and is >> intended only for the named recipient(s) and may contain information that >> is privileged, proprietary, attorney work product or exempt from disclosure >> under applicable law. If you have received this message in error, or are >> not the named recipient(s), please note that any form of distribution, >> copying or use of this communication or the information in it is strictly >> prohibited and may be unlawful. Please immediately notify the sender of the >> error, and delete this communication including any attached files from your >> system. Thank you for your cooperation. >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
