Good point.
Certainly depends on the type of reseller we're dealing with. If it's a
company, each instance will likely share the network. If it's a university
(let's say), each student may be on their own network.
This may fall into the Distributed Scheduler camp ... don't allocate new
instanc
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
w
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
w
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 ins
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 ou
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 expensi
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
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 use
> From: Vishvananda Ishaya [vishvana...@gmail.com]
>
> Ok, as I read it now, the resource groups are really a different terminology
> for the same thing we were discussing before. The difference is that in this
> model the resource group always ends up as the "owner" of the project.
Correct, s
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 orga
Ok, as I read it now, the resource groups are really a different terminology
for the same thing we were discussing before. The difference is that in this
model the resource group always ends up as the "owner" of the project.
I would still suggest that this makes some actions inside a service ve
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
accou
Hello everyone,
As a reminder, our weekly team meeting will take place at 21:00 UTC
this Tuesday in #openstack-meeting on IRC.
Check out how that time translates for *your* timezone:
http://timeanddate.com/s/202f
See the meeting agenda, edit the wiki to add new topics for discussion:
http://wiki
2011/4/4 Thomas Goirand :
> 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 and massive
14 matches
Mail list logo
