The DELETE call that John mentioned must be sent to a proxy server configured with "allow_account_management = true". Same with an account PUT.
--J On Tue, Jul 19, 2011 at 9:07 AM, John Dickinson <john.dickin...@rackspace.com> wrote: > 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 > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
