Re: [Openstack] Some Debian fixes I pushed in the launchpad bzr

2011-04-05 Thread Soren Hansen
2011/4/4 Thomas Goirand z...@debian.org: My new proposal is now: /OpenStack is a reliable cloud infrastructure. Its mission is to produces the ubiquitous cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Sandy Walsh
Doh! I'm an idiot. Write that down. Eric, you're correct, we don't need to sync the AuthZ servers. We only need to pass the Resource Group ID's along after the user authenticates (thanks Jorge for reminding me.) This is along the lines of what you have been suggesting with different User

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Vishvananda Ishaya
On Apr 4, 2011, at 6:46 PM, Eric Day wrote: Hi Vish, On Mon, Apr 04, 2011 at 05:56:38PM -0700, Vishvananda Ishaya wrote: I agree that your suggestion is simpler, but I think we are too limited if we remove multi-membership and per-object overrides. Imagine that alice is an organization

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Sandy Walsh
From: Vishvananda Ishaya [vishvana...@gmail.com] I think account/action tuple isn't too complicated. If we decide not to use use the resource_groups as tags, meaning multiple can be applied to same object, then we probably need this functionality. Or else we will have some crazy user

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Vishvananda Ishaya
On Apr 5, 2011, at 9:07 AM, Sandy Walsh wrote: groups = AuthZ.get_resource_groups('alice') instances = set() for group in groups: instances.union(set(nova.get_instances(group))) return instances Agree that this could result in lots of little queries as written above, but the db

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Sandy Walsh
From: Vishvananda Ishaya [vishvana...@gmail.com] Ok so we are aggregating at the service layer. That does make optimization a bit easier. Especially if the user can specify with the OnBehalfOf idea a subset of the instances he wants to list. Yeah, previously it would have been expensive

Re: [Openstack] Federated Identity Management (bursting and zones)

2011-04-05 Thread Vishvananda Ishaya
Just thought of something else to consider. There is a further issue with setting the owner to resource_group: Networking. In Vlan mode, each owner gets its own vlan and communication between the instances is easy. If users start dividing up instances into a bunch of sub-groups we will run

Re: [Openstack] Some Debian fixes I pushed in the launchpad bzr

2011-04-05 Thread Chuck Thier
I think you may have just hit an edge case in the ring-builder code. I don't think it likes it if you remove all the devices from the ring. There is also another edge case where some operations (like rebalancing) will fail if you have less than 3 zones. BTW, the easiest way to test a working

Re: [Openstack] dotnet cloud files access?

2011-04-05 Thread Chuck Thier
Hi Jon, I'm not familiar with the C# bindings, but the fact that you can do some operations sounds promising. A 503 return code from the server means that something wrong happened server side, so you might check the server logs to see if they provide any useful information. Another useful test