Open Stack

OK, that helps.

We have a blueprint to use a string ID instead of the integer in the database: https://blueprints.launchpad.net/keystone/+spec/portable-identifiers

I think that will address your needs (eventually).

We intend to deliver that without any API changes (the API supports string IDs) and with full migration support from stable/diablo.

To summarize the intent:

  *   we add a string UID to the database schema
  *   For deployments with the integer ID, we copy that into the UID field
  *   For deployments where the ID is a string (cactus and pre-Diablo) we copy that into the UID field
  *   We use the UID field in the URLs displayed by Keystone

That will allow migrations into Keystone and you can decide in your data import what value to make the ID that shows up as the REST URL.

This is a future answer to your need. We plan on doing this very soon (maybe by E2). But for the current Keystone schema I don't have any alternative suggestions unfortunately.

Does this help?


From: Judd Maltin <openstack at newgoliath.com<mailto:openstack at newgoliath.com>>
Date: Thu, 1 Dec 2011 16:32:00 -0500
To: Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>
Subject: Re: [Openstack] Keystone & Swift: swiftauth tenant namespace collisions?

Hi Ziad,

The current authentication systems for Swift use a hash as the tenant_id.  I saw that keystone is using a sequential integer from the DB as the tenant_id.  This doesn't allow Keystone to match an existing Swift tenant_id (called "account" in Swift).  This prevents Keystone from just "taking over" for swauth or tempauth.

If the definition of tenant_id is changed in Keystone to be configurable by the administrator, or at least NOT be a seq from the DB, then migration from swauth to keystone is possible, and may even be automated.

Looking forward to your thoughts,
-judd

On Sun, Nov 27, 2011 at 12:51 AM, Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>> wrote:
Hi Judd –

Account in swift is the same thing as tenant in Keystone.

Is the problem that you are specifying account 'name' instead of the ID?

I'm asking because we have had a number of users having problems migrating into Keystone after we switched to ID/Name for tenants and users and we are considering a schema change that would allow for simpler migration into Keystone and support tenant ID and name being the same.

I'm not sure that would help you, but if it would we would like to get your input on the design we are considering.

From: Judd Maltin <openstack at newgoliath.com<mailto:openstack at newgoliath.com>>
Date: Fri, 25 Nov 2011 11:31:50 -0500
To: "Rouault, Jason (Cloud Services)" <jason.rouault at hp.com<mailto:jason.rouault at hp.com>>
Cc: John Dickinson <me at not.mn<mailto:me at not.mn>>, Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>, "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>

Subject: Re: [Openstack] Keystone & Swift: swiftauth tenant namespace collisions?

Thanks Jason,

I am indeed working off stable/diablo.  It looks like I'm going to have to use mod_proxy and mod_rewrite to migrate my users form AUTH_<account_name> to AUTH_<tenant_id>  Any other ideas for this sort of migration?

-judd




On Mon, Nov 21, 2011 at 9:42 AM, Rouault, Jason (Cloud Services) <jason.rouault at hp.com<mailto:jason.rouault at hp.com>> wrote:
Yes, I am aware of the new swift code for Keystone, but the question came
from Judd who may be working off of Diablo-stable.

-----Original Message-----
From: John Dickinson [mailto:me at not.mn<mailto:me at not.mn>]
Sent: Sunday, November 20, 2011 8:59 AM
To: Rouault, Jason (Cloud Services)
Cc: Ziad Sawalha; Judd Maltin; openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Subject: Re: [Openstack] Keystone & Swift: swiftauth tenant namespace
collisions?

I don't think that is exactly right, but my understanding of tenants vs
accounts vs users may be lacking. Nonetheless, auth v2.0 support was added
to the swift cli tool by Chmouel recently. Have you tried with the code in
swift's trunk (also the 1.4.4 release scheduled for Tuesday)?

--John


On Nov 20, 2011, at 8:55 AM, Rouault, Jason (Cloud Services) wrote:

> Ziad,
>
> I think the problem is that the 'swift' command scopes a user to an
account(tenant) via the concatenation of account:username when providing
credentials for a valid token.  With Keystone and /v2.0 auth the tenantId
(or tenantName) are passed in the body of the request.
>
> Jason
>
> From: openstack-bounces+jason.rouault=hp.com at lists.launchpad.net<mailto:hp.com at lists.launchpad.net>
[mailto:openstack-bounces+jason.rouault<mailto:openstack-bounces%2Bjason.rouault>=hp.com at lists.launchpad.net<mailto:hp.com at lists.launchpad.net>] On
Behalf Of Ziad Sawalha
> Sent: Friday, November 18, 2011 2:10 PM
> To: Judd Maltin; openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Subject: Re: [Openstack] Keystone & Swift: swiftauth tenant namespace
collisions?
>
> Hi Judd - I'm not sire I understand. Can you give me an example of two
tenants, their usernames, and the endpoints you would like them to have in
Keystone?
>
>
> From: Judd Maltin <judd at newgoliath.com<mailto:judd at newgoliath.com>>
> Date: Fri, 18 Nov 2011 15:22:09 -0500
> To: <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>
> Subject: [Openstack] Keystone & Swift: swiftauth tenant namespace
collisions?
>
> In keystone auth for swift (swiftauth), is there a way to eliminate
namespace conflicts across tenants?"
>
> i.e. in tempauth we use account:username password
>
> curl -k  -v -H 'X-Auth-User: test:tester' -H 'X-Auth-Token: testing'
http://127.0.0.1:8080/auth/v1.0
>
> in swiftauth we use username password:
> $ swift -A http://127.0.0.1:5000/v1.0 -U joeuser -K secrete stat -v
> StorageURL: http://127.0.0.1:8888/v1/AUTH_1234
> Auth Token: 74ce1b05-e839-43b7-bd76-85ef178726c3
> Account: AUTH_12
>
> How can I indicate my tenant (aka account) in this scheme.  I already have
lots of data.
>
> Further, should I create custom endpoint templates for each tenant to
address "Account: AUTH_12" being unknown to my current swift account db?
>
> Thanks very much,
> -judd
>
>
> --
> Judd Maltin
> T: 917-882-1270<tel:917-882-1270>
> F: 501-694-7809<tel:501-694-7809>
> A loving heart is never wrong.
>
>
>
> _______________________________________________ Mailing list:
https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> Post to :openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> More help :
https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/ListHelp



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111201/7562cec7/attachment.html>