25, 2011 3:42 PM
To: Sandy Walsh
Cc: Soren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
On May 25, 2011, at 4:41 AM, Sandy Walsh wrote:
- We'd need to create a per-Flavor FanOut queue. Some Compute nodes would
express the
On May 25, 2011, at 4:41 AM, Sandy Walsh wrote:
>
> - We'd need to create a per-Flavor FanOut queue. Some Compute nodes would
> express their interest in handling the request and we'd, somehow, need to
> decide which one gets the work. Who would decide that? How could they do it
> without cre
t
without creating a single point of failure?
Regardless ... it's a great idea and definitely one that deserves more
consideration.
Thanks!
-S
From: Soren Hansen [so...@linux2go.dk]
Sent: Tuesday, May 24, 2011 4:56 PM
To: Sandy Walsh
Cc: openstack
2011/5/23 Sandy Walsh :
> To Soren's point about "losing the ability to rely on a fixed set of
> topics in the message queue for doing scheduling" this is not the case,
> there are no new topics introduced.
That's not exactly what I meant.
If we stuck with the simple flavours that we have right n
On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh wrote:
> Actually, I'm cool with it either way.
>
> I'm not really sure of the value in letting users generate their own
> Reservation ID though. What would the typical motivation be?
>
> That said, anyone else have preferences (PUT + user defined res
[Openstack] OpenStack API, Reservation ID's and Num Instances ...
I'm for zone-generated ids. If we take user input it is one more
thing to sanitize and scope accordingly. As the number is essentially
disposable, I don't know why they would care to provide one anyway, it
just seems like ch
POST isn't an issue for me. I honestly don't know why I wrote PUT ... I blame
the Canadian holiday.
From: Ed Leafe
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
> Hmm, not sure I like changing the return type based on the input type. Return
> typ
defined reservation ID's)
> vs. (POST + zone generated ID's)?
>
> -S
>
>
> From: Brian Lamar [brian.la...@rackspace.com]
> Sent: Tuesday, May 24, 2011 11:30 AM
> To: Sandy Walsh
> Cc: openstack@lists.launchpad.net
&
On May 24, 2011, at 10:43 AM, Sandy Walsh wrote:
> I'm not really sure of the value in letting users generate their own
> Reservation ID though. What would the typical motivation be?
>
> That said, anyone else have preferences (PUT + user defined reservation ID's)
> vs. (POST + zone generated I
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
> Hmm, not sure I like changing the return type based on the input type. Return
> types should be consistent.
Agreed, but I liked changing the meaning of PUT even less. :)
-- Ed Leafe
___
M
Hmm, not sure I like changing the return type based on the input type. Return
types should be consistent.
From: Ed Leafe
> If we are going to add an optional parameter to specify the number of
> instances, would it be acceptable to specify that when t
On May 24, 2011, at 10:30 AM, Brian Lamar wrote:
> Only a small scream on PUT /zones/server/
>
> PUT would work in my mind if we allowed users to create their own
> ReservationIDs, but since (I assume) we're generating them it would make more
> sense to me to use POST on /zones/server.
ated ID's)?
-S
From: Brian Lamar [brian.la...@rackspace.com]
Sent: Tuesday, May 24, 2011 11:30 AM
To: Sandy Walsh
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Only a small scream on PUT
nt: Monday, May 23, 2011 5:54pm
To: "openstack@lists.launchpad.net"
Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Thanks to all for the input. I don't think we've really come to any conclusions
for the near term.
Unless someone screams, w
On Mon, May 23, 2011 at 5:54 PM, Sandy Walsh wrote:
> We can have Feats of Strength later to decide how this should live on in an
> OS API 2.0 world.
I'll bring the Festivus pole.
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to :
Thanks to all for the input. I don't think we've really come to any conclusions
for the near term.
Unless someone screams, we will be proceeding along the following lines:
1. Adding PUT /zones/server/ to create an instance that will return a
Reservation ID (a UUID). It will also accept a num-in
Also keep in mind that UUIDs alone may not be sufficient. As was
discussed previously in a marathon ID rename thread, we have to
handle the case of federated zones gone bad that could purposefully
produce UUIDs that collide. We may want any extra namespace such as
"account:uuid" or "zone:uuid", but
+1
On May 23, 2011, at 11:54 AM, Vishvananda Ishaya wrote:
> So I think we've identified the real problem...
>
> :)
>
> sounds like we really need to do the UUID switchover to optimize here.
>
> Vish
>
> On May 23, 2011, at 9:42 AM, Jay Pipes wrote:
>
>> On Mon, May 23, 2011 at 12:33 PM, Bri
_
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Mark Washenberger [mark.washenber...@rackspace.com]
Sent: Monday, May 23, 2011 1:54 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack API, Reserva
So I think we've identified the real problem...
:)
sounds like we really need to do the UUID switchover to optimize here.
Vish
On May 23, 2011, at 9:42 AM, Jay Pipes wrote:
> On Mon, May 23, 2011 at 12:33 PM, Brian Schott
> wrote:
>> Why does getting the instance id require the API to block?
I'm totally on board with this as a future revision of the OS api. However it
sounds like we need some sort of solution for 1.1.
> 1. We can't treat the InstanceID as a ReservationID since they do two
> different
> things. InstanceID's are unique per instance and ReservationID's might span N
> i
On Mon, May 23, 2011 at 12:33 PM, Brian Schott
wrote:
> Why does getting the instance id require the API to block? I can create 1 or
> 1000 UUIDs in order (1) time in the API server and hand back 1000 instance
> ids in a list of entries in the same amount of time.
Instance IDs aren't currentl
Why does getting the instance id require the API to block? I can create 1 or
1000 UUIDs in order (1) time in the API server and hand back 1000 instance ids
in a list of entries in the same amount of time. I'm more concerned
about an external user hitting the API server 1000 times to generate
On May 23, 2011, at 11:25 AM, Sandy Walsh wrote:
From: Jorge Williams
> So this is 2.0 API stuff -- right.
Well, we need it now ... so we have to find a short term solution.
> Why not simply have a request on the server list with the reservation id as a
> parameter.
> This can easily be suppo
From: Jorge Williams
> So this is 2.0 API stuff -- right.
Well, we need it now ... so we have to find a short term solution.
> Why not simply have a request on the server list with the reservation id as a
> parameter.
> This can easily be supported as an extension.
>
> So GET /servers/detail?R
On May 23, 2011, at 11:53 AM, Sandy Walsh wrote:
> Likewise, we need a way to query the results of a Reservation ID request
> without busting GET /servers/detail ... perhaps GET /zones/servers could do
> that?
GET /servers/reservation/ perhaps? Returns a list of instances
similar
I'd like to step back and denote that there won't be support for this in the
1.1 API -- unless this is an extension. So this is 2.0 API stuff -- right.
Other comments inline:
On May 23, 2011, at 10:53 AM, Sandy Walsh wrote:
Cool, I think you all understand the concerns here:
1. We can't tre
Cool, I think you all understand the concerns here:
1. We can't treat the InstanceID as a ReservationID since they do two different
things. InstanceID's are unique per instance and ReservationID's might span N
instances. I don't like the idea of overloading these concepts. How is the
caller sup
On May 23, 2011, at 11:41 AM, Jorge Williams wrote:
> I don't see how that peculates anything. Treat the instance id as the
> reservation id on single instance creations -- have a separate reservation id
> when launching multiple instances. End of the day even if you have the
> capability to
On May 23, 2011, at 10:15 AM, Ed Leafe wrote:
> On May 23, 2011, at 10:35 AM, Jorge Williams wrote:
>
>> If we make the instance ID a unique ID -- which we probably should. Why
>> not also treat it as a reservation id and generate/assign it up front?
>
>
> Because that precludes the 1
On May 23, 2011, at 10:15 AM, Jay Pipes wrote:
> /me wishes you were on IRC ;)
>
> Discussing this with Mark Wash on IRC...
>
I'll stop by :-)
> Basically, I'm cool with using a UUID-like pregenerated instance ID
> and returning that as a reservation ID in the 1.X API.
Cool.
> I was really
On May 23, 2011, at 10:35 AM, Jorge Williams wrote:
> If we make the instance ID a unique ID -- which we probably should. Why not
> also treat it as a reservation id and generate/assign it up front?
Because that precludes the 1:M relationship of a reservation to created
instances.
/me wishes you were on IRC ;)
Discussing this with Mark Wash on IRC...
Basically, I'm cool with using a UUID-like pregenerated instance ID
and returning that as a reservation ID in the 1.X API. I was really
just brainstorming about a future, request-centric 2.0 API that would
allow for more atomi
2011/5/23 Sandy Walsh :
> Additionally, and less important at this stage, users at the summit
> expressed an interest in being able to specify instances with something
> richer than Flavors. We have some mockups in the current host-filter code
> for doing this using a primitive little JSON grammar.
2011/5/23 Mark Washenberger :
> If I understand the features correctly, their implementation in nova seems
> straightforward. However, I am still a little curious about their necessity.
> For load balancing, what is the difference between a single request for N
> instances and N requests for a s
Comments inline:
On May 23, 2011, at 8:59 AM, Jay Pipes wrote:
> Hi Jorge! Comments inline :)
>
> On Mon, May 23, 2011 at 9:42 AM, Jorge Williams
> wrote:
>> Hi Sandy,
>> My understanding (Correct me if i'm wrong here guys) is that creating
>> multiple instances with a single call is not in sco
Hi Jorge! Comments inline :)
On Mon, May 23, 2011 at 9:42 AM, Jorge Williams
wrote:
> Hi Sandy,
> My understanding (Correct me if i'm wrong here guys) is that creating
> multiple instances with a single call is not in scope for the 1.1 API.
Actually, I don't think we *could* do this without issu
Hi Sandy,
My understanding (Correct me if i'm wrong here guys) is that creating multiple
instances with a single call is not in scope for the 1.1 API. Same thing for
changing the way in which flavors work. Both features can be brought in as
extensions though.
I should note that when creating
Sandy,
If I understand the features correctly, their implementation in nova seems
straightforward. However, I am still a little curious about their necessity.
For load balancing, what is the difference between a single request for N
instances and N requests for a single instance each?
"Sandy W
Hi everyone,
We're deep into the Zone / Distributed Scheduler merges and stumbling onto an
interesting problem.
EC2 API has two important concepts that I don't see in OS API (1.0 or 1.1):
- Reservation ID
- Number of Instances to create
Typical use case: "Create 1000 instances". The API allocat
40 matches
Mail list logo
