<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> So I'm going to implement a partition of 1 billion integers per zone, which should allow for approximately 1 billion zones, given a 64 bit integer for the PK. This should be workable for now, and after the design summit, when we've come to a consensus on changing the API to accept something other than integer identifiers, it should not be too difficult to retrofit.<br>
</blockquote><div><br></div><div>The type of a server @id in CloudServers is xsd:int, which is a 32-bit signed integer:</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><a href="http://docs.rackspacecloud.com/servers/api/v1.0/xsd/server.xsd">http://docs.rackspacecloud.com/servers/api/v1.0/xsd/server.xsd</a></div>
<div><br></div><div>So if you have 1 billion integers per zone, you only get 2 zones.  You can have 4 if you're willing to go negative, but surely it's too early in the campaign.<a href="http://docs.rackspacecloud.com/servers/api/v1.0/xsd/server.xsd"></a></div>
<div><br></div><div>I think the only way long-term we're going to have CloudServers v1.0 compatibility is by having a proxy that bridges between legacy APIs (EC2 and CS) and future APIs (OpenStack).  I'm guessing that proxy will have to be stateful to implement mappings of server IDs etc.  Yes, this sucks.  But at some stage you have to say "you know, maybe 640KB wasn't enough, and we have to make some changes"</div>
<div><br></div><div>How about this as a solution: use ranges as you suggest, but let the starting points for the zone-ids that child-zones draw from be customer-configured.  We're pushing the problem onto the end-user, but they probably know best anyway, and we don't really expect anyone to use sub-zones in anger anyway until Diablo or later, right?</div>
<div><br></div><div>Justin</div></div>