The API spec doesn't seem to preclude us from doing a fully-synchronous method if we want to (it just reserves the option to do an async implementation).  Obviously we should make scheduling fast, but I think we're fine doing synchronous scheduling.  It's still probably going to be much faster than CloudServers on a bad day anyway :-)<div>
<br></div><div>Anyone have a link to where we chose to go with integer IDs?  I'd like to understand why, because presumably we had a good reason.</div><div><br></div><div>However, if we don't have documentation of the decision, then I vote that it never happened, and instance ids are strings.  We've always been at war with Eastasia, and all ids have always been strings.<br>
<div><br></div><div>Justin</div><div><br><br>
<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 12:20 PM, Paul Voccio <span dir="ltr"><<a href="mailto:paul.voccio@rackspace.com">paul.voccio@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I agree with the sentiment that integers aren't the way to go long term.<br>
The current spec of the api does introduce some interesting problems to<br>
this discussion. All can be solved. The spec calls for the api to return<br>
an id and a password upon instance creation. This means the api isn't<br>
asynchronous if it has to wait for the zone to create the id. From page 46<br>
of the API Spec states the following:<br>
<br>
"Note that when creating a server only the server ID and the admin<br>
password are guaranteed to be returned in the request object. Additional<br>
attributes may be retrieved by performing subsequent GETs on the server."<br>
<br>
<br>
<br>
This creates a problem with the bursting if Z1 calls to Z2, which is a<br>
public cloud, which has to wait for Z3-X to find out where it is going be<br>
placed. How would this work?<br>
<br>
pvo<br>
<div><div></div><div class="h5"><br>
On 3/22/11 1:39 PM, "Chris Behrens" <<a href="mailto:chris.behrens@rackspace.com">chris.behrens@rackspace.com</a>> wrote:<br>
<br>
><br>
>I think Dragon got it right.  We need a zone identifier prefix on the<br>
>IDs.  I think we need to get away from numbers.  I don't see any reason<br>
>why they need to be numbers.  But, even if they did, you can pick very<br>
>large numbers and reserve some bits for zone ID.<br>
><br>
>- Chris<br>
><br>
><br>
>On Mar 22, 2011, at 10:48 AM, Justin Santa Barbara wrote:<br>
><br>
>> I think _if_ we want to stick with straight numbers, the following are<br>
>>the 'traditional' choices:<br>
>><br>
>> 1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers<br>
>>2,4,6.  Requires that you know in advance how many zones there are.<br>
>> 2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx.<br>
>> 3) Central allocation - each zone would request an ID from a central<br>
>>pool.  This might not be a bad thing, if you do want to have a quick<br>
>>lookup table of ID -> zone.  Doesn't work if the zones aren't under the<br>
>>same administrative control.<br>
>> 4) Block allocation - a refinement of #3, where you get a bunch of IDs.<br>
>> Effectively amortizes the cost of the RPC.  Probably not worth the<br>
>>effort here.<br>
>><br>
>> (If you want central allocation without a shared database, that's also<br>
>>possible, but requires some trickier protocols.)<br>
>><br>
>> However, I agree with Monsyne: numeric IDs have got to go.  Suppose I'm<br>
>>a customer of Rackspace CloudServers once it is running on OpenStack,<br>
>>and I also have a private cloud that the new Rackspace Cloud Business<br>
>>unit has built for me.  I like both, and then I want to do cloud<br>
>>bursting in between them, by putting an aggregating zone in front of<br>
>>them.  I think at that stage, we're screwed unless we figure this out<br>
>>now.  And this scenario only has one provider (Rackspace) involved!<br>
>><br>
>> We can square the circle however - if we want numbers, let's use UUIDs<br>
>>- they're 128 bit numbers, and won't in practice collide.  I'd still<br>
>>prefer strings though...<br>
>><br>
>> Justin<br>
>><br>
>><br>
>><br>
>> On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br>
>>        I want to get some input from all of you on what you think is<br>
>>the best way to approach this problem: the RS API requires that every<br>
>>instance have a unique ID, and we are currently creating these IDs by<br>
>>use of an auto-increment field in the instances table. The introduction<br>
>>of zones complicates this, as each zone has its own database.<br>
>><br>
>>        The two obvious solutions are a) a single, shared database and<br>
>>b) using a UUID instead of an integer for the ID. Both of these<br>
>>approaches have been discussed and rejected, so let's not bring them<br>
>>back up now.<br>
>><br>
>>        Given integer IDs and separate databases, the only obvious<br>
>>choice is partitioning the numeric space so that each zone starts its<br>
>>auto-incrementing at a different point, with enough room between<br>
>>starting ranges to ensure that they would never overlap. This would<br>
>>require some assumptions be made about the maximum number of instances<br>
>>that would ever be created in a single zone in order to determine how<br>
>>much numeric space that zone would need. I'm looking to get some<br>
>>feedback on what would seem to be reasonable guesses to these partition<br>
>>sizes.<br>
>><br>
>>        The other concern is more aesthetic than technical: we can make<br>
>>the numeric spaces big enough to avoid overlap, but then we'll have very<br>
>>large ID values; e.g., 10 or more digits for an instance. Computers<br>
>>won't care, but people might, so I thought I'd at least bring up this<br>
>>potential objection.<br>
>><br>
>><br>
>><br>
>> -- Ed Leafe<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
>_______________________________________________<br>
>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</div></div></blockquote></div><br></div></div>