+1
Great discussion and not anything that should be blocking distributed
scheduler.
-S
From: Eric Day [e...@oddments.org]
Ok. :) The original statement felt like it was written with negative
connotations, and I just wanted to say I think it's all
If we were to go with UUIDs and using XenServer, I should be able to use
the uuid that it generates upon VM creation. I would almost ask your above
question for XenServer then. When I terminate and launch an VM on the same
machine, I should be able to give it the same uuid that I was just
It's early here, but I think it's closer to 200 zones? :)
On Mar 24, 2011, at 5:16 AM, Ed Leafe e...@leafe.com wrote:
On Mar 23, 2011, at 9:41 PM, Justin Santa Barbara wrote:
The type of a server @id in CloudServers is xsd:int, which is a 32-bit
signed integer:
Good conversation guys. Certainly something we need to get settled out sooner
than later.
On naming:
No matter how we shake it out (prefixes, mac address, time, etc), we're
essentially fabricating our own form of UUID ... trying to pick some unique
qualifier(s) to avoid collisions.
I think
Subject: Re: [Openstack] Instance IDs and Multiple Zones
Good conversation guys. Certainly something we need to get settled out
sooner than later.
On naming:
No matter how we shake it out (prefixes, mac address, time, etc), we're
essentially fabricating our own form of UUID ... trying
On Mar 23, 2011, at 8:46 AM, Ewan Mellor wrote:
We have to accept that, on the scales we care about, any unique ID is going
to be incomprehensible to a human. Rely on your presentation layer, that's
what it's there for!
+1
-- Ed Leafe
On Mar 23, 2011, at 11:28 AM, Chris Behrens wrote:
How would the admin API know which ID to work with if there are collisions?
Eric's point is that we'd not know where to route the request.
This reflects a fundamental misunderstanding of the way inter-zone
communication works.
You have a fundamental misunderstanding of my fundamental understanding of how
inter-zone communication works. :) I understand how it works. I'm asking
about an admin API that has privileges for actions for all VMs. As an ISP, I
want to disable a particular VM because it's being 'bad'. If
Hi Ed,
On Wed, Mar 23, 2011 at 08:15:54AM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 1:55 AM, Eric Day wrote:
If we provide some structure to the IDs, such as DNS names, we not only
solve this namespacing problem but we also get a much more efficient
routing mechanism.
When I
Pvo brought up a good use case for naming a little while ago: Migrations.
If we use the instance id (assume UNC) to provide hints to the target zone,
this means the instance id would need to change should the instance move
locations. That's a no-no by everyone's measure.
So, now I'm thinking
I asked for further details in IRC, which started a discussion
there. To sum up, most folks agree migrations within a zone won't
require a new instance ID. Nothing changes except the compute host
it's running on. Migrations outside of a zone would require a new
instance ID, but this should be
On Mar 23, 2011, at 3:00 PM, Eric Day wrote:
Migrations outside of a zone would require a new
instance ID, but this should be fine, since other things would also
change (such as IP, available volumes, ...).
That's probably true in the Rackspace use case, as zones would most
likely
On Wed, Mar 23, 2011 at 07:40:20PM +, Ed Leafe wrote:
Migrations outside of a zone would require a new
instance ID, but this should be fine, since other things would also
change (such as IP, available volumes, ...).
That's probably true in the Rackspace use case, as zones would
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-
bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Justin Santa
Barbara
Sent: 23 March 2011 19:22
To: Eric Day
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IDs
-Original Message-
From: Paul Voccio [mailto:paul.voc...@rackspace.com]
Sent: 23 March 2011 22:19
To: Ewan Mellor; Justin Santa Barbara; Eric Day
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IDs and Multiple Zones
I don't agree at all. There are many good
OK, time for everyone to step back and take a deep breath.
There are many implications of the earlier design decision to use
integer PKs for database entries. Most who have responded here, myself
included, have indicated that they would prefer that this be changed to either
a
(sorry Eric, meant to send to the list)
-S
From: Eric Day [e...@oddments.org]
Do we want this namespace per zone, deployment, resource owner, or some other
dimension?
Good question. We can prevent collisions at the zone level and within a
deployment (single provider / multi-zone). But hybrid
On Thu, Mar 24, 2011 at 12:23:42AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Do we want this namespace per zone, deployment, resource owner, or some
other dimension?
Good question. We can prevent collisions at the zone level and within a
deployment (single provider /
From: Eric Day [e...@oddments.org]
On Thu, Mar 24, 2011 at 12:23:42AM +, Sandy Walsh wrote:
Regardless of how we delineate it or which ID scheme we use, we have no way
of detecting collisions.
Why not? Some schemes such as the ID.DNS name + ssl cert check I
mentioned before allow us
On Mar 23, 2011, at 8:59 PM, Eric Day wrote:
May I ask what is the point of doing this if it won't make cactus and
we're just going to replace it in a month or two? I think we all agree
that 64-bit integer IDs are insufficient for multi-zone deployments,
so no one will be deploying this until
Hi Sandy,
On Thu, Mar 24, 2011 at 01:01:18AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Within that zone Nova will prevent collisions, but if things are really
broken (accident or on purpose)
and it starts returning duplicate resource IDs, peer zones can choose to just
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
On Mar 23, 2011, at 9:54 PM, Eric Day wrote:
I don't think anyone is arguing, all the discussion has been very
healthy IMHO.
Of course we are arguing - presenting evidence for a particular
position in an effort to persuade is argument. The arguments have not become
heated or
Ok. :) The original statement felt like it was written with negative
connotations, and I just wanted to say I think it's all been positive.
-Eric
On Wed, Mar 23, 2011 at 10:09:50PM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 9:54 PM, Eric Day wrote:
I don't think anyone is arguing, all the
the IDs must be strictly numericalish numbers, with nothing smelling
of something like a string in there, i take it?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
On Mar 22, 2011, at 1:11 PM, Jon Slenk wrote:
the IDs must be strictly numericalish numbers, with nothing smelling
of something like a string in there, i take it?
Well, since they are defined as: `id` int(11) NOT NULL AUTO_INCREMENT,
I would say the chance of a stringish thing
On Tue, Mar 22, 2011 at 10:41 AM, Ed Leafe e...@leafe.com wrote:
Well, since they are defined as: `id` int(11) NOT NULL AUTO_INCREMENT,
I would say the chance of a stringish thing slipping in is pretty small. :)
if the schema cannot be changed (which might be worth reconsidering
since it
I think _if_ we want to stick with straight numbers, the following are the
'traditional' choices:
1) Skipping - so zone1 would allocate numbers 1,3,5, zone2 numbers 2,4,6.
Requires that you know in advance how many zones there are.
2) Prefixing - so zone0 would get 0xxx, zone1 1xx.
3)
Also, I should note that there seems to be merges pending to make the
v1.1 api use urls as instance identifiers in api calls, rather than
integer id's...
I'm not sure of the impact of that with the v1.0 compat, but that is
something to think of.
--
--
-Monsyne Dragon
Confidentiality
On Tue, Mar 22, 2011 at 12:40:21PM -0400, Ed Leafe wrote:
The two obvious solutions are a) a single, shared database and b) using
a UUID instead of an integer for the ID. Both of these approaches have been
discussed and rejected, so let's not bring them back up now.
We shouldn't
On Mar 22, 2011, at 1:45 PM, Jon Slenk wrote:
if the schema cannot be changed (which might be worth reconsidering
since it seems to be a bit of a root cause of trouble) then maybe you
have to reserve the last 4 or 5 digits of the id to be the zone id,
and then autoincrement on top of that? on
On Tue, Mar 22, 2011 at 10:48:09AM -0700, Justin Santa Barbara wrote:
We can square the circle however - if we want numbers, let's use UUIDs -
they're 128 bit numbers, and won't in practice collide. I'd still prefer
strings though...
If we use a number/uuid without a zone prefix,
Totally agree with Eric.
Two questions that I think can help us move forward:
1. Is the decision to stick with integers still valid? Can someone that
was there give us the reason for the decision? Is it documented anywhere?
2. If we must have integers means that we get 128 bit
I think Dragon got it right. We need a zone identifier prefix on the IDs. I
think we need to get away from numbers. I don't see any reason why they need
to be numbers. But, even if they did, you can pick very large numbers and
reserve some bits for zone ID.
- Chris
On Mar 22, 2011, at
I know you don't want to resurrect a past discussion. But, UUIDs are
designed to solve these kind of problems, frankly. The decision to go
with integer IDs is a poor one, and will be negatively affecting the
scalability and architecture of our systems well into the future.
I'd love to see a
I agree with the sentiment that integers aren't the way to go long term.
The current spec of the api does introduce some interesting problems to
this discussion. All can be solved. The spec calls for the api to return
an id and a password upon instance creation. This means the api isn't
] Instance IDs and Multiple Zones
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
EC2 uses xsd:string for their instance id. I can't find any additional
guarantees.
Here's a (second hand) quote from Amazon:
http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever
Instance ids are unique. You'll never receive a duplicate id. However, the
current
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.
This approach might help us in fixing some of the nastier bits of the openstack
api images
Yes, that is what they say, Unfortunately all of the ec2 tools expect the
current format that they are using to various degrees.
Some just need the proper prefix (euca2ools)
Others need the prefix + hex (elasticfox, irrc)
Others allow a string but limit it to 11 chars, etc.
So to keep
+1
Sounds like some IPV6 discussions back when the standards were being debated.
We could debate bit-allocation forever. Why can't we use UUIDs?
http://tools.ietf.org/html/rfc4122
2. Motivation
One of the main reasons for using UUIDs is that no centralized
authority is required to
Seems resonable
+1 to design summit discussion
Vish
On Mar 22, 2011, at 1:06 PM, Justin Santa Barbara wrote:
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 :-)
We
I remember reading this a while ago. Not saying we have to do this. This is
probably why zones are independent and ids are not unique across zones in EC2.
This could be handled in the ec2 api service for compatibility. We could just
XOR the top half and the bottom half of a UUID and get a
See my previous response to Justin's email as to why UUIDs alone are
not sifficient.
-Eric
On Tue, Mar 22, 2011 at 04:06:14PM -0400, Brian Schott wrote:
+1
Sounds like some IPV6 discussions back when the standards were being debated.
We could debate bit-allocation forever. Why can't we use
Good discussion. I need to understand a bit more about how cross org
boundary bursting is envisioned to work before assessing the implications
on server id format.
Say a user hits the http://servers.myos.com api on zone A, which then
calls out to http://servers.osprovider.com api in zone B,
Pure numeric ids will not work in a federated model at scale.
Agreed
Maybe I'm missing something, but I don't see how you could inject a
collision ID downstream - you can just shoot yourself in your own foot.
I think that you can get away with it only in simple hierarchical
structures.
46 matches
Mail list logo
