How does one get a list of all accounts in Swift? GET /v1/ does not work. Returns Bad URL.
If there does exist a way, then: Will this return all enabled (non-deleted) and disabled (marked deleted) accounts? Can this be filtered (deleted, non-deleted) Thanks Divyesh -----Original Message----- From: John Dickinson [mailto:john.dickin...@rackspace.com] Sent: Tuesday, July 19, 2011 10:08 AM To: Khandeshi, Divyesh Cc: 'openstack@lists.launchpad.net' Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account Account deletes need to be handled by a DELETE call on the account to the swift cluster. This would need to be set up as some separate process in your account management system. --John On Jul 19, 2011, at 8:55 AM, Khandeshi, Divyesh wrote: > Hi John, > > Thanks for the quick API info. > > Going back to the lazy model for provisioning accounts, how do you handle > account deletions? Essentially, the issue here is that since the > account_autocreate flag only handles creation, what happens when, say, a > tenant is deleted from Keystone? How does that deletion get propagated/synced > to Swift? Who or how would the account tombstones be set? > > Thanks > > Divyesh > > > -----Original Message----- > From: John Dickinson [mailto:john.dickin...@rackspace.com] > Sent: Monday, July 18, 2011 5:03 PM > To: Khandeshi, Divyesh > Cc: 'openstack@lists.launchpad.net' > Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account > > The security implications are tied to what credentials as user gets from the > auth server you are using. The possibility is that a user could delete their > own account (or even another user's account) or create new accounts. > Disabling allow_account_management eliminates these issues by disabling the > functionality. > > There are no formal docs of this part of the API. It's quite simple though: > PUT/POST/GET/HEAD/DELETE to /v1/"your account string" > > --John > > > On Jul 18, 2011, at 3:00 PM, Khandeshi, Divyesh wrote: > >> John, >> >> Sorry, hit the send button too fast.. >> >> What are the security implications? >> >> Thanks >> >> Divyesh >> >> -----Original Message----- >> From: openstack-bounces+divyesh.khandeshi=hp....@lists.launchpad.net >> [mailto:openstack-bounces+divyesh.khandeshi=hp....@lists.launchpad.net] On >> Behalf Of Khandeshi, Divyesh >> Sent: Monday, July 18, 2011 3:56 PM >> To: John Dickinson >> Cc: 'openstack@lists.launchpad.net' >> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >> >> John, >> >> Thanks for the information. >> >> When you mention PUT/DELETE accounts - where is this API documented? Or >> could you provide more details for the supported methods? >> >> Thanks >> >> Divyesh >> >> -----Original Message----- >> From: John Dickinson [mailto:john.dickin...@rackspace.com] >> Sent: Monday, July 18, 2011 3:41 PM >> To: Khandeshi, Divyesh >> Cc: Ziad Sawalha; 'openstack@lists.launchpad.net' >> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >> >> To provision an account in a swift cluster without using the autocreate >> option, you must run a proxy server with the allow_account_management option >> set to True. Your auth system then needs to PUT/DELETE accounts to that >> proxy server as necessary. There are security implications here (which is >> why the value defaults to false), so you should take care to ensure that >> only your auth server can talk to the proxy server with this option turned >> on. >> >> --John >> >> >> On Jul 18, 2011, at 2:05 PM, Khandeshi, Divyesh wrote: >> >>> Hi Ziad, >>> >>> Thanks for your responses. >>> >>> So Swift will authenticate against Keystone directly with the method you >>> describe below? But is there an actual sync mechanism to sync >>> keystone(tenant) -> swift(account)? account_autocreate provides the lazy >>> option. >>> >>> Sorry for repeating this (and may be Swift folks can possibly help): What >>> API/method does Rackspace dashboard use to manage accounts in Swift? >>> Essentially, is there any exposed API access for managing accounts in Swift >>> (non-lazy option). The swift_auth.py appears to only handle auth cases >>> including Swift auth but does not actually provide account management >>> (Swift account CRUD). >>> >>> Thanks >>> >>> Divyesh >>> >>> >>> From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] >>> Sent: Monday, July 18, 2011 11:41 AM >>> To: Khandeshi, Divyesh; 'openstack@lists.launchpad.net' >>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> Hi Divyesh - additional info I just got: >>> >>> "run with account_autocreate = True. As long as account ids == tenant >>> names, you should be fine. For example, if you request /v1.0/AUTH_foobar >>> and you have the foobar tenant then it will try to authorize against the >>> foobar tenant." >>> >>> Z >>> >>> From: "Khandeshi, Divyesh" <divyesh.khande...@hp.com> >>> Date: Mon, 18 Jul 2011 15:47:31 +0100 >>> To: Ziad Sawalha <ziad.sawa...@rackspace.com>, >>> "'openstack@lists.launchpad.net'" <openstack@lists.launchpad.net> >>> Subject: RE: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> Ziad, >>> >>> 1. You mention that Nova has a shim for lazy syncing of accounts with >>> Keystone. What about Swift? Or the account_autocreate (in >>> proxy-server.conf) the only option to achieve this? >>> 2. As to the Rackspace dashboard, what API does it use for provisioning? >>> Is it a Rackspace-only API or some undocumented/unexposed Account >>> management API in Swift? >>> >>> Thanks >>> >>> Divyesh >>> >>> >>> From: openstack-bounces+divyesh.khandeshi=hp....@lists.launchpad.net >>> [mailto:openstack-bounces+divyesh.khandeshi=hp....@lists.launchpad.net] On >>> Behalf Of Ziad Sawalha >>> Sent: Saturday, July 16, 2011 3:30 PM >>> To: Nguyen, Liem Manh; 'openstack@lists.launchpad.net' >>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> Swift account and tenant should be the same. This does not prescribe that >>> Swift not store them locally (Nova still stores projects). >>> >>> The synchronization can be lazy (Nova does this with a shim in Keystone. If >>> a request is authorized by Keystone on a tenant that does not have a >>> corresponding project, it creates it right there and then). Or it can be >>> proactive (as opposed to lazy). >>> >>> For proactive provisioning (where accounts would be synched to swift when >>> they are created. >>> >>> Summarizing: >>> Lazy provisioning: Users and tenants are created as authenticated requests >>> come in to the openstack service for the first time. >>> Proactive provisioning: Users and tenants are created in all services as >>> they are created in Keystone. >>> ,Ote: my personal preference is for lazy provisioning. >>> >>> For proactive provisioning, we would need a service to own orchestration >>> (or provisioning or order fullfilment - pick your model). We don't have one >>> today. The Dashboard does some of that. Rackspace does it using >>> non-openstack components which contain Rackspace business logic. >>> Will this ever become an OpenStack project or wiL this always live in the >>> business systems of the operator (an enterprise deploying and operating >>> openstack)... >>> >>> Z >>> >>> From: Nguyen, Liem Manh [mailto:liem_m_ngu...@hp.com] >>> Sent: Friday, July 15, 2011 05:56 PM >>> To: openstack@lists.launchpad.net <openstack@lists.launchpad.net> >>> Subject: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account >>> >>> Hi, >>> >>> For Nova, the Keystone Tenant maps to a Nova project, and according to the >>> "Finalize Auth integration" blueprint, the Nova project is going away ("no >>> more project/roleuser info in nova"). >>> >>> What about Swift's account? I assume the Keystone tenant would map to a >>> Swift account. How would this mapping occur? Would Swift still maintain >>> account information in the db and these will get synchronized with Keystone >>> tenant information (i.e., auto-create accounts), or would Swift get rid of >>> the account concept and have a mapping between tenant and containers >>> instead? If there is any existing blue-print/docs on Keystone/Swift >>> integration plan for Diablo, that would be greatly appreciated. >>> >>> Thanks, >>> Liem >>> This email may include confidential information. If you received it in >>> error, please delete it. >>> This email may include confidential information. If you received it in >>> error, please delete it. >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : 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 > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
