Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Actually, myself and Soren were talking about this over IRC earlier today. Soren has a theory that we may not even need respond back to the caller for a you win decision to be made. The receiving compute node could just act on it straight away. I think he's correct. If you can't handle the request, don't listen for it. No fanout required. Remember that this proposal only really works with Flavor-based scheduling and not ad-hoc capability-oriented scheduling. Which means ... the whole Scheduler concept potentially goes away. All the Zone stuff and the Cost computation stuff would stay the same, just move location. The use case that causes problems is the one I mentioned earlier: prefer hosts that don't already hold instances for this customer ... which requires compute nodes to know about each others state. But I think we can handle this in the following way: - Modulo the number of Compute nodes by some number X. This is our stripe number. - Keep a per-customer reference to the last stripe used (S, an int) - When requesting a new instance, ask for a Compute node of Stripe (S + 1) % X - Compute nodes listen for Flavors on their Stripe only This implies we need # Flavors * # Stripes queues, but queues are lightweight anyway. Still stewing on the ramifications of all this. -S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Wednesday, May 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 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 creating a single point of failure? Mesos has an interesing way of doing this, where there is an external scheduler that receives offers for resources and can choose to take the offers or not. http://www.cs.brown.edu/courses/csci2950-u/f10/papers/mesos_tech_report.pdf This would definitely be a radical difference from what we are doing, but perhaps we could provide some sort of webhook where we can pass sanitized offers back to clients and they can decide whether to take them or not. Vish Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
On Mon, May 23, 2011 at 5:54 PM, Sandy Walsh sandy.wa...@rackspace.com 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 : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net 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, 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-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 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 Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... 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. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net 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, 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-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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. Agreed. Server creation should certainly be a POST. If we are going to add an optional parameter to specify the number of instances, would it be acceptable to specify that when that parameter is included, a reservation ID is returned instead of an instance ID? IOW, existing calls will work the same, but calls that take advantage of this new option would expect a different result. -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 that parameter is included, a reservation ID is returned instead of an instance ID? IOW, existing calls will work the same, but calls that take advantage of this new option would expect a different result. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 ID's)? Easy - user-generated reservation IDs would almost certainly result in duplicates. Imagine if 3rd parties using the API each set up a system that generated sequential integer reservation IDs... -- Ed Leafe ___ 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] 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 changing who is responsible for making a uuid. On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh sandy.wa...@rackspace.com 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 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 Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... 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. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net 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, 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-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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 types should be consistent. Agreed, but I liked changing the meaning of PUT even less. :) -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
Yup ... agreed. I'll press on in this direction (POST with zone generated ID's) -S From: Todd Willey [t...@ansolabs.com] Sent: Tuesday, May 24, 2011 12:13 PM To: Sandy Walsh Cc: Brian Lamar; openstack@lists.launchpad.net Subject: Re: [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 changing who is responsible for making a uuid. On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh sandy.wa...@rackspace.com 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 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 Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... 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. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net 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, 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-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
2011/5/23 Sandy Walsh sandy.wa...@rackspace.com: 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 now, we could schedule stuff exclusively using the message queue. The scheduler would not need to know *anything* about the various compute nodes. Scheduling an instance of flavour X would be achieved simply by sending a run this instance message on the message queue with the flavour-X topic. Any compute node able to accommodate an instance of that size would be subscribed to that topic, and the message queue would simply route the message to a random one of them. As a compute node fills up, it'll unsubscribe from the topics representing flavours that it no longer has room for. This sounds Very Scalable[tm] to me :) Even if all the scheduling attributes we come up with were discrete and enumerable, the cartesian product of all of them is potentially *huge*, so having a topic for each of the possible combinations sounds like very little fun. If any of them are not enumerable, it gets even less fun. So, adding these capabilities would get in the way of implementing something like the above. I guess it could be a configuration option, i.e. if you choose the rich scheduling option set, you don't get to use the cool scheduler. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack API, Reservation ID's and Num Instances ...
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 allocates a Reservation ID and all the instances are created until this ID. The ID is immediately returned to the user who can later query on this ID to check status. From what I can see, the OS API only deals with single instance creation and returns the Instance ID from the call. Both of these need to change to support Reservation ID's and creating N instances. The value of the distributed scheduler comes from being able to create N instances load balanced across zones. Anyone have any suggestions how we can support this? 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. So, let's assume the Flavor-like query would just be a string. Thoughts? -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 single instances the instance id should really be equivalent to a reservation id. That is, the create should be asynchronous and the instance id can be used to poll for changes. Because of this, a user can create multiple instances in very rapid succession. Additionally, the changes-since feature in the API allows a user to efficiently monitor the creation of multiple instances simultaneously. -jOrGe W. On May 23, 2011, at 7:19 AM, Sandy Walsh wrote: 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 allocates a Reservation ID and all the instances are created until this ID. The ID is immediately returned to the user who can later query on this ID to check status. From what I can see, the OS API only deals with single instance creation and returns the Instance ID from the call. Both of these need to change to support Reservation ID's and creating N instances. The value of the distributed scheduler comes from being able to create N instances load balanced across zones. Anyone have any suggestions how we can support this? 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. So, let's assume the Flavor-like query would just be a string. Thoughts? -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.commailto:ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] OpenStack API, Reservation ID's and Num Instances ...
Hi Jorge! Comments inline :) On Mon, May 23, 2011 at 9:42 AM, Jorge Williams jorge.willi...@rackspace.com 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 issuing a 2.0 API. The reason is because changing POST /servers to return a reservation ID instead of the instance ID would break existing clients, and therefore a new major API version would be needed. Same thing for changing the way in which flavors work. Both features can be brought in as extensions though. Sorry, I'm not quite sure I understand what you mean by changing the way flavours work. Could you elaborate a bit on that? I should note that when creating single instances the instance id should really be equivalent to a reservation id. That is, the create should be asynchronous and the instance id can be used to poll for changes. Hmm, it's actually a bit different. In one case, you need to actually get an identifier for the instance from whatever database (zone db?) would be responsible for creating the instance. In the other case, you merely create a token/task that can then be queried for a status of the operation. In the former case, you unfortunately make the scheduler's work synchronous, since the instance identifier would need to be determined from the zone the instance would be created in. :( Because of this, a user can create multiple instances in very rapid succession. Not really the same as issuing a request to create 100 instances. Not only would the user interface implications be different, but you can also do all-or-nothing scheduling with a request for 100 instances versus 100 requests for a single instance. All-or-nothing allows a provider to pin a request to a specific SLA or policy. For example, if a client requests 100 instances be created with requirements X, Y, and Z, and you create 88 instances and 12 instances don't get created because there is no more available room that meets requirements X, Y, and Z, then you have failed to service the entire request... Additionally, the changes-since feature in the API allows a user to efficiently monitor the creation of multiple instances simultaneously. Agreed, but I think that is tangential to the above discussion. Cheers! jay -jOrGe W. On May 23, 2011, at 7:19 AM, Sandy Walsh wrote: 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 allocates a Reservation ID and all the instances are created until this ID. The ID is immediately returned to the user who can later query on this ID to check status. From what I can see, the OS API only deals with single instance creation and returns the Instance ID from the call. Both of these need to change to support Reservation ID's and creating N instances. The value of the distributed scheduler comes from being able to create N instances load balanced across zones. Anyone have any suggestions how we can support this? 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. So, let's assume the Flavor-like query would just be a string. Thoughts? -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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
jorge.willi...@rackspace.com 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 issuing a 2.0 API.
The reason is because changing POST /servers to return a reservation
ID instead of the instance ID would break existing clients, and
therefore a new major API version would be needed.
Why? Clients just see an ID. I'm suggesting that for single instances, the
instanceID == the reservationID.
In the API you query based on Some ID.
http://my.openstack-compute.net/v1.1/2233/servers/{Some unique ID}
Same
thing for changing the way in which flavors work. Both features can be
brought in as extensions though.
Sorry, I'm not quite sure I understand what you mean by changing the
way flavours work. Could you elaborate a bit on that?
Sandy was suggesting we employ a method richer than Flavors. I'll let him
elaborate.
I should note that when creating single instances the instance id should
really be equivalent to a reservation id. That is, the create should be
asynchronous and the instance id can be used to poll for changes.
Hmm, it's actually a bit different. In one case, you need to actually
get an identifier for the instance from whatever database (zone db?)
would be responsible for creating the instance. In the other case, you
merely create a token/task that can then be queried for a status of
the operation. In the former case, you unfortunately make the
scheduler's work synchronous, since the instance identifier would need
to be determined from the zone the instance would be created in. :(
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
of this, a user can create multiple instances in very rapid succession.
Not really the same as issuing a request to create 100 instances. Not
only would the user interface implications be different, but you can
also do all-or-nothing scheduling with a request for 100 instances
versus 100 requests for a single instance. All-or-nothing allows a
provider to pin a request to a specific SLA or policy. For example, if
a client requests 100 instances be created with requirements X, Y, and
Z, and you create 88 instances and 12 instances don't get created
because there is no more available room that meets requirements X, Y,
and Z, then you have failed to service the entire request...
I totally understand this. I'm just suggesting that since this is not is scope
for 1.1 -- you should be able to launch individual instances as an alternative.
Also, keep in mind that the all-or-nothing requires a compensation when
something fails.
Additionally, the changes-since feature in the API allows a user to
efficiently monitor the creation of multiple instances simultaneously.
Agreed, but I think that is tangential to the above discussion.
Cheers!
jay
-jOrGe W.
On May 23, 2011, at 7:19 AM, Sandy Walsh wrote:
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 allocates a Reservation
ID and all the instances are created until this ID. The ID is immediately
returned to the user who can later query on this ID to check status.
From what I can see, the OS API only deals with single instance creation and
returns the Instance ID from the call. Both of these need to change to
support Reservation ID's and creating N instances. The value of the
distributed scheduler comes from being able to create N instances load
balanced across zones.
Anyone have any suggestions how we can support this?
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. So, let's assume the
Flavor-like query would just be a string. Thoughts?
-S
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of
the
individual or entity to which this message is addressed, and unless
otherwise
expressly indicated, is confidential and privileged information of
Rackspace.
Any dissemination, distribution or copying of the enclosed material is
prohibited.
If you receive this transmission in error, please notify us immediately by
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
2011/5/23 Mark Washenberger mark.washenber...@rackspace.com: 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? Scheduling. If you ask for 10 instances in one call, they're scheduled as a set. The entire call either fails or succeeds and all the instances land in the same availability zone. 10 individual requests will cause each of the instances to be scheduled individually (partial failures and being scattered across multiple availability zones being the major problems). -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] OpenStack API, Reservation ID's and Num 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 atomic operations on the instance creation level.
Cheers!
jay
On Mon, May 23, 2011 at 10:35 AM, Jorge Williams
jorge.willi...@rackspace.com wrote:
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
jorge.willi...@rackspace.com 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 issuing a 2.0 API.
The reason is because changing POST /servers to return a reservation
ID instead of the instance ID would break existing clients, and
therefore a new major API version would be needed.
Why? Clients just see an ID. I'm suggesting that for single instances, the
instanceID == the reservationID.
In the API you query based on Some ID.
http://my.openstack-compute.net/v1.1/2233/servers/{Some unique ID}
Same
thing for changing the way in which flavors work. Both features can be
brought in as extensions though.
Sorry, I'm not quite sure I understand what you mean by changing the
way flavours work. Could you elaborate a bit on that?
Sandy was suggesting we employ a method richer than Flavors. I'll let him
elaborate.
I should note that when creating single instances the instance id should
really be equivalent to a reservation id. That is, the create should be
asynchronous and the instance id can be used to poll for changes.
Hmm, it's actually a bit different. In one case, you need to actually
get an identifier for the instance from whatever database (zone db?)
would be responsible for creating the instance. In the other case, you
merely create a token/task that can then be queried for a status of
the operation. In the former case, you unfortunately make the
scheduler's work synchronous, since the instance identifier would need
to be determined from the zone the instance would be created in. :(
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
of this, a user can create multiple instances in very rapid succession.
Not really the same as issuing a request to create 100 instances. Not
only would the user interface implications be different, but you can
also do all-or-nothing scheduling with a request for 100 instances
versus 100 requests for a single instance. All-or-nothing allows a
provider to pin a request to a specific SLA or policy. For example, if
a client requests 100 instances be created with requirements X, Y, and
Z, and you create 88 instances and 12 instances don't get created
because there is no more available room that meets requirements X, Y,
and Z, then you have failed to service the entire request...
I totally understand this. I'm just suggesting that since this is not is
scope for 1.1 -- you should be able to launch individual instances as an
alternative.
Also, keep in mind that the all-or-nothing requires a compensation when
something fails.
Additionally, the changes-since feature in the API allows a user to
efficiently monitor the creation of multiple instances simultaneously.
Agreed, but I think that is tangential to the above discussion.
Cheers!
jay
-jOrGe W.
On May 23, 2011, at 7:19 AM, Sandy Walsh wrote:
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 allocates a Reservation
ID and all the instances are created until this ID. The ID is immediately
returned to the user who can later query on this ID to check status.
From what I can see, the OS API only deals with single instance creation and
returns the Instance ID from the call. Both of these need to change to
support Reservation ID's and creating N instances. The value of the
distributed scheduler comes from being able to create N instances load
balanced across zones.
Anyone have any suggestions how we can support this?
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. So, let's assume the
Flavor-like query would just be a string. Thoughts?
-S
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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
just brainstorming about a future, request-centric 2.0 API that would
allow for more atomic operations on the instance creation level.
Okay, I'll follow up.
Cheers!
jay
On Mon, May 23, 2011 at 10:35 AM, Jorge Williams
jorge.willi...@rackspace.com wrote:
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
jorge.willi...@rackspace.com 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 issuing a 2.0 API.
The reason is because changing POST /servers to return a reservation
ID instead of the instance ID would break existing clients, and
therefore a new major API version would be needed.
Why? Clients just see an ID. I'm suggesting that for single instances, the
instanceID == the reservationID.
In the API you query based on Some ID.
http://my.openstack-compute.net/v1.1/2233/servers/{Some unique ID}
Same
thing for changing the way in which flavors work. Both features can be
brought in as extensions though.
Sorry, I'm not quite sure I understand what you mean by changing the
way flavours work. Could you elaborate a bit on that?
Sandy was suggesting we employ a method richer than Flavors. I'll let him
elaborate.
I should note that when creating single instances the instance id should
really be equivalent to a reservation id. That is, the create should be
asynchronous and the instance id can be used to poll for changes.
Hmm, it's actually a bit different. In one case, you need to actually
get an identifier for the instance from whatever database (zone db?)
would be responsible for creating the instance. In the other case, you
merely create a token/task that can then be queried for a status of
the operation. In the former case, you unfortunately make the
scheduler's work synchronous, since the instance identifier would need
to be determined from the zone the instance would be created in. :(
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
of this, a user can create multiple instances in very rapid succession.
Not really the same as issuing a request to create 100 instances. Not
only would the user interface implications be different, but you can
also do all-or-nothing scheduling with a request for 100 instances
versus 100 requests for a single instance. All-or-nothing allows a
provider to pin a request to a specific SLA or policy. For example, if
a client requests 100 instances be created with requirements X, Y, and
Z, and you create 88 instances and 12 instances don't get created
because there is no more available room that meets requirements X, Y,
and Z, then you have failed to service the entire request...
I totally understand this. I'm just suggesting that since this is not is
scope for 1.1 -- you should be able to launch individual instances as an
alternative.
Also, keep in mind that the all-or-nothing requires a compensation when
something fails.
Additionally, the changes-since feature in the API allows a user to
efficiently monitor the creation of multiple instances simultaneously.
Agreed, but I think that is tangential to the above discussion.
Cheers!
jay
-jOrGe W.
On May 23, 2011, at 7:19 AM, Sandy Walsh wrote:
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 allocates a Reservation
ID and all the instances are created until this ID. The ID is immediately
returned to the user who can later query on this ID to check status.
From what I can see, the OS API only deals with single instance creation
and
returns the Instance ID from the call. Both of these need to change to
support Reservation ID's and creating N instances. The value of the
distributed scheduler comes from being able to create N instances load
balanced across zones.
Anyone have any suggestions how we can support this?
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. So, let's assume the
Flavor-like query would
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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:M relationship of a reservation to created instances. If I request 100 instances, they are all created with unique IDs, but with a single reservation ID. 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 launch multiple instances at once you should be able to poll a specific instance for changes. -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 launch multiple instances at once you should be able to poll a specific instance for changes. I'm not too crazy about an API call returning one thing (instance ID) for one call, and a different thing (reservation ID) for the same call, with the only difference being the value of one parameter. Do we do anything like that anywhere else in the API? Also, with distributed zones, getting an instance ID requires the api to block until the host selection can be completed, and the host's zone database updated with the new instance information. Granted, that's not an agonizingly slow or expensive operation even if it does involve several inter-zone HTTP calls, but it isn't the cleanest and most scalable design IMO. -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 to GET /servers. -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 supported as an extension. So GET /servers/detail?RID=3993882 I would probably call it a build ID. That would narrow the response to only those that are currently being build with a single request (3993882). I'm cool with that ... why does it need to be an extension, per se? It's just an additional parameter which will be ignored until something going looking for it. To prevent clashes. To detect if the feature is available -- it probably wont be available in our legacy system. How about the POST /zones/server idea? I'll have to think about it. -S ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 server entries in the same amount of time. I'm more concerned about an external user hitting the API server 1000 times to generate a 1000 instance request, then hitting the API server 1000 more times to check the status until a 1000 instances return running. That's a lot of socket connections. The SeverDetailsResponse isn't a list? You can't just return: server ... /server server ... /server server ... /server Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com On May 23, 2011, at 11:52 AM, Ed Leafe wrote: 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 launch multiple instances at once you should be able to poll a specific instance for changes. I'm not too crazy about an API call returning one thing (instance ID) for one call, and a different thing (reservation ID) for the same call, with the only difference being the value of one parameter. Do we do anything like that anywhere else in the API? Also, with distributed zones, getting an instance ID requires the api to block until the host selection can be completed, and the host's zone database updated with the new instance information. Granted, that's not an agonizingly slow or expensive operation even if it does involve several inter-zone HTTP calls, but it isn't the cleanest and most scalable design IMO. -- Ed Leafe ___ 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] OpenStack API, Reservation ID's and Num Instances ...
On Mon, May 23, 2011 at 12:33 PM, Brian Schott brian.sch...@nimbisservices.com 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 server entries in the same amount of time. Instance IDs aren't currently UUIDs :) They are auto-increment integers that are local to the zone database. And because they are currently assigned by the zone, the work of identifying the appropriate zone to place a requested instance in would need to be a synchronous operation (you can't have the instance ID until you find the zone to put it in). -jay ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 instances. I don't like the idea of overloading these concepts. How is the caller supposed to know if they're getting back a ReservationID or an InstanceID? How to they ask for updates for each (one returns a single value, one returns a list?). Rather than overloading the two, could we just make instance-id a uuid asynchronous and pare down the amount of info returned in the server create response? 2. We need to handle provision N instances so the scheduler can effectively load balance the requests by looking at the current state of the system in a single view. Concurrent single-shot requests would be picked up by many different schedulers in many different zones and give an erratic distribution. Are we worried about concurrent or rapid sequential requests? Is there any way we could cut down on the erraticism by funneling these types of requests through a smaller set of schedulers? I'm very unfamiliar with the scheduler system but it seems like maybe routing choices at a higher level scheduler could help here. 3. and 4. sound like great features albeit ones that could wait on a future revision of the api. Apologies if I'm speaking out of turn and should just read up on scheduler code! Sandy Walsh sandy.wa...@rackspace.com said: ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp 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 supposed to know if they're getting back a ReservationID or an InstanceID? How to they ask for updates for each (one returns a single value, one returns a list?). 2. We need to handle provision N instances so the scheduler can effectively load balance the requests by looking at the current state of the system in a single view. Concurrent single-shot requests would be picked up by many different schedulers in many different zones and give an erratic distribution. 3. As Soren pointed out, we may want certain semantics around failure such as all or nothing 4. Other Nova users have mentioned a desire for instance requests such as has GPU, is in North America and has a blue sticker on the box. If we try to do that with Flavors we need to clutter the Flavor table with most-common-denominator fields. We can handle this now with Zone/Host Capabilities and not have to extend the table at all. If you look at nova/tests/scheduler/test_host_filter.py you'll see an example of this in action. 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. Instead there are simply extra arguments passed into the run_instance() method of the scheduler that understands these more complex instance requests. That said, I was thinking of adding a POST /zone/server command to support these extended operations. It wouldn't affect anything currently in place and makes it clear that this is a zone-specific operation. Existing EC2 and core OS API operations are performed as usual. 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? The downside is that now we have two ways to create an instance that needs to be tested, etc. -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ 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] OpenStack API, Reservation ID's and Num Instances ...
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 brian.sch...@nimbisservices.com 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 server entries in the same amount of time. Instance IDs aren't currently UUIDs :) They are auto-increment integers that are local to the zone database. And because they are currently assigned by the zone, the work of identifying the appropriate zone to place a requested instance in would need to be a synchronous operation (you can't have the instance ID until you find the zone to put it in). -jay ___ 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] OpenStack API, Reservation ID's and Num Instances ...
Changing to UUID is a great thing to do, but not sure if it solves our problem. We still need to differentiate between an Instance ID and a Reservation ID. Additionally, switching to UUID has to be a 2.0 thing, since it's going to bust all backwards compatibility. The ability to cast to int() is a general assumption in RS API clients. With respect to multiple single-shot requests, assume 10 schedulers pick up 10 instance requests concurrently. Their view of the world will be largely the same so they will all attempt to provision to the same host. VS a single request for 10 instances where the scheduler can be smart about where it attempts to place them. And then there's the socket / api server load from 1000 single-shot requests as mentioned elsewhere in this thread. I agree that 3 4 may be nice to haves. I've simply heard explicit demand for #4 from customers and I don't believe the delta to get their is that high. -S PS You're not speaking out of turn. I need to do a better job of articulating the zones/dist-sched architecture ... it's underway :) 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, Reservation ID's and Num Instances ... 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 instances. I don't like the idea of overloading these concepts. How is the caller supposed to know if they're getting back a ReservationID or an InstanceID? How to they ask for updates for each (one returns a single value, one returns a list?). Rather than overloading the two, could we just make instance-id a uuid asynchronous and pare down the amount of info returned in the server create response? 2. We need to handle provision N instances so the scheduler can effectively load balance the requests by looking at the current state of the system in a single view. Concurrent single-shot requests would be picked up by many different schedulers in many different zones and give an erratic distribution. Are we worried about concurrent or rapid sequential requests? Is there any way we could cut down on the erraticism by funneling these types of requests through a smaller set of schedulers? I'm very unfamiliar with the scheduler system but it seems like maybe routing choices at a higher level scheduler could help here. 3. and 4. sound like great features albeit ones that could wait on a future revision of the api. Apologies if I'm speaking out of turn and should just read up on scheduler code! Sandy Walsh sandy.wa...@rackspace.com said: ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp 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 supposed to know if they're getting back a ReservationID or an InstanceID? How to they ask for updates for each (one returns a single value, one returns a list?). 2. We need to handle provision N instances so the scheduler can effectively load balance the requests by looking at the current state of the system in a single view. Concurrent single-shot requests would be picked up by many different schedulers in many different zones and give an erratic distribution. 3. As Soren pointed out, we may want certain semantics around failure such as all or nothing 4. Other Nova users have mentioned a desire for instance requests such as has GPU, is in North America and has a blue sticker on the box. If we try to do that with Flavors we need to clutter the Flavor table with most-common-denominator fields. We can handle this now with Zone/Host Capabilities and not have to extend the table at all. If you look at nova/tests/scheduler/test_host_filter.py you'll see an example of this in action. 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. Instead there are simply extra arguments passed into the run_instance() method of the scheduler that understands these more complex instance requests. That said, I was thinking of adding a POST
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
+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, Brian Schott brian.sch...@nimbisservices.com 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 server entries in the same amount of time. Instance IDs aren't currently UUIDs :) They are auto-increment integers that are local to the zone database. And because they are currently assigned by the zone, the work of identifying the appropriate zone to place a requested instance in would need to be a synchronous operation (you can't have the instance ID until you find the zone to put it in). -jay ___ 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
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
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 of course we need to figure out federated account and zone details first. -Eric On Mon, May 23, 2011 at 05:28:20PM +, Jorge Williams wrote: +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, Brian Schott brian.sch...@nimbisservices.com 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 server entries in the same amount of time. Instance IDs aren't currently UUIDs :) They are auto-increment integers that are local to the zone database. And because they are currently assigned by the zone, the work of identifying the appropriate zone to place a requested instance in would need to be a synchronous operation (you can't have the instance ID until you find the zone to put it in). -jay ___ 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
