It's early here, but I think it's closer to 200 zones? :)
On Mar 24, 2011, at 5:16 AM, Ed Leafe 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:
>> http://docs.rackspacecloud.com/ser
> 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 u
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:
> http://docs.rackspacecloud.com/servers/api/v1.0/xsd/server.xsd
>
> So if you have 1 billion integers per zone, you only get 2 zones. You can
> h
+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 been
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 t
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 person
On Wed, Mar 23, 2011 at 09:15:38PM -0400, Ed Leafe wrote:
> 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 insufficie
>
> 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 someth
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 ju
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 un
> 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 all
Hi Ed,
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 we sort it out and come up
with a better I
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 prov
(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 hybri
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 st
On Wed, Mar 23, 2011 at 11:09:01PM +, Sandy Walsh wrote:
> From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> > To your point about the boundary of preservation of ID, that's a good
> > question. If you ignore the security / trust issues, then the obvious
> > answer is that IDs should be global
Thanks for the clarification. I wasn't sure if you were actually
contradicting yourself as it seemed such an odd thing for you to do. : )
More below!
>
>I certainly didn't intend for those statements to be contradictory. I
>don't think that they are.
Thanks for the clarification. I wasn't sure
From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> For example, if I charge my customers for a month of usage, even if they only
> run the VM for a part of that month, then my billing system needs to be able
> to say "that VM has moved from here to here, but it's actually the same VM,
> so I'm cha
> -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
>
>I don't agree at all. There are many good reasons to preserve the
>identity of a VM even when it's IP or location changes. Billing, for
>example. Access control. Intrusion detection.
>
>Just because I move a VM from one place to another, why would I expect
>its identity to change?
>
>
Wh
Re: [Openstack] Instance IDs and Multiple Zones
>
> > 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, ...). A cross-zone migration
> > will be more of a copy+d
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 zone
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
>
> 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, ...). A cross-zone migration
> will be more of a copy+delete than a proper move.
+1 on this. If the IP is changing, there's little p
Indeed, migrations are a major fly in the ointment for any strategy for
meaningful naming (i.e. anything that doesn't use a central DB). It's not
clear to me with cross-zone migrations that we (a) can keep the same ID and
(b) want to keep the same ID even if we could...
We could look at tricks li
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 fine,
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 m
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.
>
>
>
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 so
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. The
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.
On Mar 23, 2011, at 5:15 AM, 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 name
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
__
rch 2011 12:30
> To: openstack@lists.launchpad.net
> 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, e
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 t
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 read things like this, the DBA in me winces a little. Meaningful
PKs,
Hi Erik,
You bring up some really great points and possible solutions. Comments
inline:
On Wed, Mar 23, 2011 at 01:02:55AM +, Erik Carlin wrote:
> I assume the lowest zone (zone D) is responsible for assigning the id?
Yes, the zone that actually contains the running VM should be the
fully qu
Ed,
I spoke with Jorge earlier today and this is still treated as the instance
id. That instance can fail or succeed, but the id of what you call to
retrieve that status never changes.
pvo
On 3/22/11 2:55 PM, "Ed Leafe" wrote:
>On Mar 22, 2011, at 3:20 PM, Paul Voccio wrote:
>
>> This means t
> 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.
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, which
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 u
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
I'd like to point out that while I agree with moving to strings (and
using UUIDs as internal identifiers), this is a discussion for the
summit, and under no circumstances should anyone get the impression
that a change to the identifier will be occurring for Cactus!
-jay
On Tue, Mar 22, 2011 at 4:
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 :-)
>
+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
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 should also start engaging with client tools, because we're never going
to be 100% EC2 compatible. At the least, our en
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 compatibi
On Tue, Mar 22, 2011 at 3:29 PM, Ed Leafe wrote:
> On Mar 22, 2011, at 2:53 PM, Jay Pipes wrote:
>
>> 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 negativ
> 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 image
On Mar 22, 2011, at 3:20 PM, Paul Voccio wrote:
> This means the api isn't
> asynchronous if it has to wait for the zone to create the id. From page 46
> of the API Spec states the following:
>
> "Note that when creating a server only the server ID and the admin
> password are guaranteed to be re
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 for
o mailto:paul.voc...@rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>, Chris
Behrens mailto:chris.behr...@rackspace.com>>
Subject: Re: [Openstack] Instance IDs and Multiple Zones
The main issue th
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
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
On Mar 22, 2011, at 2:53 PM, Jay Pipes wrote:
> 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
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
asynchronou
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 discus
Without fixing the integer ID problem, I'd vote for reserving some bits for
zone ID. I don't like the idea assigning ranges to zones. But I think the
right answer is to fix the integer ID problem.
On Mar 22, 2011, at 11:28 AM, Ed Leafe wrote:
> On Mar 22, 2011, at 1:45 PM, Jon Slenk wrote:
>
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 10
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 'rand
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, 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 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 dism
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 N
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) C
On Tue, Mar 22, 2011 at 10:41 AM, Ed Leafe 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 seems to be
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 slippi
On 3/22/11 11:40 AM, Ed Leafe wrote:
I want to get some input from all of you on what you think is the best
way to approach this problem: the RS API requires that every instance have a
unique ID, and we are currently creating these IDs by use of an auto-increment
field in the instances
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 : https://launchpad.net/~opens
I want to get some input from all of you on what you think is the best
way to approach this problem: the RS API requires that every instance have a
unique ID, and we are currently creating these IDs by use of an auto-increment
field in the instances table. The introduction of zones compl
69 matches
Mail list logo
