Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
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
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
Re: [Openstack] Adding Volume Types to Nova Volume
Both ideas seem good and reasonable to me. :) -jay On Mon, Jul 18, 2011 at 7:05 PM, Chuck Thier cth...@gmail.com wrote: There are two concepts that I would like Nova Volumes to support: 1. Allow different storage classes within a storage driver. For example, in our case we will have some nodes with high iops capabilities and other nodes for cheaper/larger volumes. 2. Allow for different storage backends to be used and specified by the user. For example, you might want to use both the Lunr volume backend, and one of the SAN backends. I think having the idea of a volume type when creating a volume would support both of these features. I have started a blueprint and spec below, and would like to solicit feedback. Blueprint: https://blueprints.launchpad.net/nova/+spec/volume-type Spec: http://etherpad.openstack.org/volume-type Please let me know what you think, and if you have any questions. -- Chuck ___ 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
Re: [Openstack] Adding Volume Types to Nova Volume
Chuck, This is very welcome in light of LUNR's refactoring. The first concept outlined was supported by an example of differing performance tiers. I'd elaborate by indicating that classes of storage can be defined on the basis of performance (which itself is nuanced: latency, throughput, IOP/s), protection policies, availability, is it cached, cloned, deduplicated, compressed, encrypted, et cetera? Nova volume needs to support some notion of those characteristics as well. Thanks, Rob Esker On Jul 18, 2011, at 6:05 PM, Chuck Thier wrote: There are two concepts that I would like Nova Volumes to support: 1. Allow different storage classes within a storage driver. For example, in our case we will have some nodes with high iops capabilities and other nodes for cheaper/larger volumes. 2. Allow for different storage backends to be used and specified by the user. For example, you might want to use both the Lunr volume backend, and one of the SAN backends. I think having the idea of a volume type when creating a volume would support both of these features. I have started a blueprint and spec below, and would like to solicit feedback. Blueprint: https://blueprints.launchpad.net/nova/+spec/volume-type Spec: http://etherpad.openstack.org/volume-type Please let me know what you think, and if you have any questions. -- Chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ 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] FLAG --start_guests_on_host_boot=true
Hmm, this flag needs to be set when the instance is created, so it will only work for new instances. I'm not sure if this flag was in cactus or not. As a workaround, you can manually turn on autostart for the domains using virsh on the compute host virsh autostart instance-0001 (for example) Vish On Jul 15, 2011, at 7:13 AM, Leandro Reox wrote: HI all, Cant find any reference about this flag on the openstack docs --start_guests_on_host_boot=true, is really available ? If so, even if i setted up on hthe compute nova.conf, doesnt restart instances at node reboot Using Cactus by now Any clues ? Regards ___ 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
Re: [Openstack] VNC consoles for all
Hi Anthony, Understood. If that's the case, I'm okay with leaving things the way they are. We already have the modification in our fork of the Dashboard but we want to upgrade to Diablo as soon as we can. Thanks, Everett On Thu, Jul 14, 2011 at 11:36 AM, Anthony Young sleepsonthefl...@gmail.comwrote: The main issue was that maintaining ec2 extensions was becoming too hairy, which is why the original doc talks about using the direct api client to get a console url. Dashboard support for vnc was subsequently added through the community using dashboard's ec2 extensions. Proper support for vnc consoles and other features that diverge from the ec2 is coming as we transition away from ec2 to the openstack api and extensions. The very latest trunk version of dashboard supports vnc consoles for all users through os extensions, and actually doesn't use ec2 at all. That said, UX-wise, I'd expect that any user should be able to access the console of an instance that was launched by their tenant. So it probably still makes sense to make the change you suggest to support older ec2-based dashboards. Anthony On Thu, Jul 14, 2011 at 8:51 AM, Everett Toews everett.to...@cybera.cawrote: The way the code stands right now is that only the cloudadmin user can view VNC consoles from the Dashboard ( http://nova.openstack.org/runnova/vncconsole.html) Is that the intention? Do we want to allow non-cloudadmin users to be able to view VNC consoles from the Dashboard? If so we need to add one line to https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py in Authorizer.__init__. Add to self.action_roles 'GetVncConsole': ['projectmanager', 'sysadmin'], under CloudController. Otherwise regular users immediately get a 401 when trying to use VNC. Everett ___ 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
