<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Seems resonable<div><br></div><div>+1 to design summit discussion</div><div><br></div><div>Vish</div><div><br><div><div>On Mar 22, 2011, at 1:06 PM, Justin Santa Barbara wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Let's take a leadership position here and go with strings; we're not breaking Amazon's API.  AWS will have to make the same changes when they reach our scale and ambition :-)<div><br></div><div>We should also start engaging with client tools, because we're never going to be 100% EC2 compatible.  At the least, our endpoints will be different.<div>
<br></div><div><div><div>I think we should discuss this at the Design Summit, and then make an effort on this front as part of Diablo.</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 12:58 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">Yes, that is what they say,  Unfortunately all of the ec2 tools expect the current format that they are using to various degrees.<div>
<br></div><div>Some just need the proper prefix (euca2ools)</div><div>Others need the prefix + hex (elasticfox, irrc)</div><div>Others allow a string but limit it to 11 chars, etc.</div><div><br></div><div>So to keep compatibility we are stuck mimicking amazon's string version for now.</div>
<div><br></div><div>Vish</div><div><div></div><div class="h5"><div><br><div><div>On Mar 22, 2011, at 12:51 PM, Justin Santa Barbara wrote:</div><br><blockquote type="cite">EC2 uses xsd:string for their instance id.  I can't find any additional guarantees.<div>
<br></div><div>Here's a (second hand) quote from Amazon:</div><div><br></div><div><a href="http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever" target="_blank">http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever</a></div>

<div><span style="border-collapse:collapse;font-family:Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif;font-size:14px;line-height:18px">"Instance ids are unique. You'll never receive a duplicate id. However, the current format of the instance id is an implementation detail that is subject to change. If you use the instance id as a string, you should be fine."</span></div>

<div><font face="Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif"><span style="border-collapse:collapse;font-size:14px;line-height:18px"><br></span></font></div>
<div>So, strings it is then? :-)<br><div><div><br>
<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 12:44 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">The main issue that drove integers is backwards compatibility to the ec2_api and existing ec2 toolsets.  People seemed very opposed to the idea of having two separate ids in the database, one for ec2 and one for the underlying system.  If we want to move to another id scheme that doesn't fit in a 32 bit integer we have to provide a way for ec2 style ids to be assigned to instances, perhaps through a central authority that hands out unique ids.<br>

<div><div><br></div><div>Vish</div><div><div></div><div><div><br></div><div>On Mar 22, 2011, at 12:30 PM, Justin Santa Barbara wrote:</div><br><blockquote type="cite">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" target="_blank">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><br>
On 3/22/11 1:39 PM, "Chris Behrens" <<a href="mailto:chris.behrens@rackspace.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
_______________________________________________<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" target="_blank">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>

</blockquote></div></div></div><br></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></body></html>