On Jul 11, 2011, at 9:23 AM, Sandy Walsh wrote:
> Ugh, sorry, burned again by outlook web. Let me continue ...
>
> I'm still stewing on this but at first blush this seems like an artificial
> abstraction. What do we really gain from having another layer above the
> service api's? Can't they jus
On Jul 11, 2011, at 6:19 PM, Ewan Mellor wrote:
>> [Snip summary]
>>
>> The only question that needs to be considered is where do we move
>> from here? Do we accept the limitation that the EC2 API and any tool
>> which relies upon that will be only available for single-zone
>> deployments,
>
> 2. Could we not have plain vanilla EC2 at the top-level zone and do all the
> funky stuff under the hood, mapping EC2 artifacts to OS artifacts as needed?
> If EC2 wants 8-character with a prefix, we can map it to our UUID's across
> Zones, but with obvious limitations. If EC2 runs out of s
Hello everyone,
This is the first time that I post on the list so please accept my
apologies if I come in "late" to the conversation.
I understand that Rackspace does not intend to add an EC2
implementation, or rather that it's not of importance to them.
However, this is something that's importa
Openstack] Cross-zone instance identifiers in EC2 API -
> Is it worth the effort?
>
> On Jul 11, 2011, at 6:46 PM, Ed Leafe wrote:
>
> >> If so, then I would say that your proposed limitation above is not
> acceptable. We don't want a situation where tenants have to
> -Original Message-
> From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
> Sent: 11 July 2011 17:10
> To: Ewan Mellor; Ed Leafe; Eric Day
> Cc: openstack@lists.launchpad.net
> Subject: RE: [Openstack] Cross-zone instance identifiers in EC2 API -
> Is it worth
___
From: Soren Hansen [so...@linux2go.dk]
> I can think of a number of reasons why using ipv6 addresses are a bad idea.
Sorry for the red-herring on the IPv6 thing. I only mentioned it in terms of
being able to use it for zone-routing. I wasn't proposing usi
I'd add a fairly fundamental rule of ID design is that ID should never, ever
have any meaning except to serve as identifiers. The minute you tie them to
IPv6 values, you are giving them meaning.
On Jul 11, 2011, at 6:49 PM, Soren Hansen wrote:
> 2011/7/11 Ed Leafe :
>> On Jul 11, 2011, at 2:04
From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> If so, then I would say that your proposed limitation above is not
> acceptable. We don't want a situation where tenants have to stop using the
> EC2 API as soon as their service provider wants to offer a rich set of
> offerings.
Hmm, two concer
On Jul 11, 2011, at 6:46 PM, Ed Leafe wrote:
>> If so, then I would say that your proposed limitation above is not
>> acceptable. We don't want a situation where tenants have to stop using the
>> EC2 API as soon as their service provider wants to offer a rich set of
>> offerings.
>
> Th
Den 11/07/2011 19.08 skrev "Brian Schott" :
> On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote:
> > 2) Use the first 8 chars, and accept an occasional duplicate ID.
> +1 this will be incredibly rare, just return an API error if
request is ambiguous
> > 3) Use the first 8 chars, but add duplication ch
2011/7/11 Ed Leafe :
> On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
> It's a shame that the ipv6 proposal was never more fully considered. That
> would handle the uniqueness, with the added benefit of providing simple zone
> routing via DNS, with the exact same 128-bit/32 char size.
I can think
2011/7/11 Ed Leafe :
>> What happens when you've shared the primary IPv6 address of a VM with
>> another VM? To which VM does the primary key point to? I think overloading
>> the IPv6 address to also mean the primary key is probably a mistake that
>> will cause serious trouble with network-as-a-
On Jul 11, 2011, at 6:19 PM, Ewan Mellor wrote:
> Up to now, I have assumed that zones would be used as the construct that
> isolated different service offerings, e.g. VMware vs XenServer or 10G
> networking versus 1G, or whatever. Zones therefore play two roles: they give
> you the architectu
> [Snip summary]
>
> The only question that needs to be considered is where do we move
> from here? Do we accept the limitation that the EC2 API and any tool
> which relies upon that will be only available for single-zone
> deployments, and if you want distributed zones, you must use the OS
>
On Jul 11, 2011, at 4:21 PM, Christopher MacGown wrote:
> What happens when you've shared the primary IPv6 address of a VM with another
> VM? To which VM does the primary key point to? I think overloading the IPv6
> address to also mean the primary key is probably a mistake that will cause
> se
___
> >> From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
> >>[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on
> >>behalf of Chris Behrens [chris.behr...@rackspace.com]
> >> Sent: Monday,
I believe we discussed this in the December timeframe. I'm still a fan of
the idea.
On 7/11/11 2:37 PM, "Eric Day" wrote:
>We did discuss using IPV6 addresses as IDs months ago (IRC and email),
>but I don't remember why we decided not to. It may have been due to
>current adoption. I think it wa
On Jul 11, 2011, at 4:03 PM, Glen Campbell wrote:
> I kind of like the IPv6 idea myself. How would it work with a service
> provider that, for example, assigns a /96 address for an instance? If the
> user can change the IP address, would that mean that the instance ID would
> change as well? Or sh
chpad.net] on
>>behalf of Chris Behrens [chris.behr...@rackspace.com]
>> Sent: Monday, July 11, 2011 4:24 PM
>> To: Ed Leafe
>> Cc: openstack@lists.launchpad.net; Chris Behrens
>> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API -
>>I
011 4:24 PM
> To: Ed Leafe
> Cc: openstack@lists.launchpad.net; Chris Behrens
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
> worth the effort?
>
> On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote:
>
>> On Jul 11, 2011, at 2:04 PM, Eric Day w
On Jul 11, 2011, at 3:24 PM, Chris Behrens wrote:
>> It's a shame that the ipv6 proposal was never more fully considered.
>> That would handle the uniqueness, with the added benefit of providing simple
>> zone routing via DNS, with the exact same 128-bit/32 char size.
>
> I don't I remembe
We did discuss using IPV6 addresses as IDs months ago (IRC and email),
but I don't remember why we decided not to. It may have been due to
current adoption. I think it was pvo who originally had the idea.
-Eric
On Mon, Jul 11, 2011 at 07:24:39PM +, Chris Behrens wrote:
>
> On Jul 11, 2011, a
On Jul 11, 2011, at 12:37 PM, Ed Leafe wrote:
> On Jul 11, 2011, at 3:24 PM, Chris Behrens wrote:
>
>>> It's a shame that the ipv6 proposal was never more fully considered.
>>> That would handle the uniqueness, with the added benefit of providing
>>> simple zone routing via DNS, with the e
.com]
Sent: Monday, July 11, 2011 4:24 PM
To: Ed Leafe
Cc: openstack@lists.launchpad.net; Chris Behrens
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote:
> On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote:
> On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
>
>>> How is
>>>
>>> nova--
>>>
>>> any different than:
>>>
>>> ----
>>>
>>> Where // (or some subset of them) are reserved/regulated?
>>
>> Nothing, if D
On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
>> How is
>>
>> nova--
>>
>> any different than:
>>
>> ----
>>
>> Where // (or some subset of them) are reserved/regulated?
>
> Nothing, if -- is a full UUID. If we compare to
> swift,
Hi Brian,
I think there may be a disconnect somewhere, perhaps we have different
deployments in mind or something. In my opinion, it seems we should
take the fully distributed, multi-tentant route to allow peering of
deployments. So whether we use UUIDs or not, the goal is to:
* Have account leve
stack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Tim Bell [tim.b...@cern.ch]
Sent: Monday, July 11, 2011 2:38 PM
To: Soren Hansen; Eric Day
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
At the ri
Eric,
I've heard this argument before, but I don't understand how can't be
injected as well to cause collisions. UUIDs can't be trusted when user
generated. As long as the UUIDs are generated consistently across all
OpenStack deployments (using the same UUID type and consistent policy on an
On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote:
> How is
>
> nova--
>
> any different than:
>
> ----
>
> Where // (or some subset of them) are reserved/regulated?
Nothing, if -- is a full UUID. If we compare to
swift,
Ahhh.. OK. The namespace is embedded in the instance ID depending on the type,
so it should be sufficient to:
GET /servers/
Regardless, uuid is sufficient and globally unique.
This doesn't consider authentication. I'd assumed that username and realm and
the like had been handled by REST-based
At the risk of making things more complicated, we should anticipate an eventual
Cloud API standard which could be any solution from EC2/OpenStack/OCCI/... and
a set of legacy interfaces for backwards compatibility. This, as far as I see,
pushes us strongly towards the multiple APIs as a present
How is
nova--
any different than:
----
Where // (or some subset of them) are reserved/regulated?
-S
This email may include confidential information. If you received it in error,
please delete it.
___
Mai
Ed,
Thanks for the succinct summary.
On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote:
> If we decide to move to a full UUID design with EC2 API as a
> first-class citizen, then we have the question of how to represent the
> 32-character UUID in the 8-character EC2 ID format. Our choices th
On Mon, Jul 11, 2011 at 06:31:14PM +0200, Soren Hansen wrote:
> >> This is only a real problem if you insist on generating them in real
> >> time rather than pre-allocate them. Each compute node could have pool
> >> of thousands of ID's it could use as it pleased. That would still
> >> allow for mi
On Jul 11, 2011, at 11:28 AM, Eric Day wrote:
>> This is only a real problem if you insist on generating them in real
>> time rather than pre-allocate them. Each compute node could have pool
>> of thousands of ID's it could use as it pleased. That would still
>> allow for millions of compute nodes
yer for existing SMB market on AWS.
>
> I'd think the Highlander approach: "There can be only one", in terms of API
> set, is what we'd be striving for.
>
> Not that I, like, have an opinion or anything. ;)
>
>
> Jan Drake
>
>
> From:
> 1) Done right, the only time I need native IDs is when I have a complex
> situation which needs debugging. It isn't the norm (or if it is, we've
> failed) -- so really I ONLY need native IDs when it's all gone pear shaped.
As the human presentation interface, sure, but the *automated* contr
2011/7/11 Eric Day :
> On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
>> 2011/7/11 Ewan Mellor :
>> > No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
>> > space, this means that you either need to allocate them incrementally
>> > (implying a distributed trans
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
> 2011/7/11 Ewan Mellor :
> > No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
> > space, this means that you either need to allocate them incrementally
> > (implying a distributed transaction across the increment
Ugh, sorry, burned again by outlook web. Let me continue ...
I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
nova.compute.api:
I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
nova.compute.api:create_instance()
vs.
nova.business_layer:create_instance()
2011/7/11 Ewan Mellor :
> No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
> space, this means that you either need to allocate them incrementally
> (implying a distributed transaction across the incrementer)
This is only a real problem if you insist on generating them in r
ng tools, so that people can get onto OpenStack as
painlessly as possible.
Cheers,
Ewan.
From: Jan Drake [mailto:jan_dr...@hotmail.com]
Sent: 11 July 2011 01:44
To: Ewan Mellor; devin.car...@gmail.com; so...@linux2go.dk
Cc: chris.behr...@rackspace.com; ed.le...@rackspace.com;
openstack@lists.launch
+0100
> CC: chris.behr...@rackspace.com; ed.le...@rackspace.com;
> openstack@lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is
> it worth the effort?
>
> > From: Devin Carlen
> >
> > Here's a few crazy questio
> From: Devin Carlen
>
> Here's a few crazy questions for you guys to consider:
>
> 1) Why are we even trying to have the same ID for an instance or image
> across two different APIs?
To reduce complexity (particularly when trying to debug the system as a whole).
> 2) How many people really swi
om
Date: Sun, 10 Jul 2011 22:53:45 -0400
To: devin.car...@gmail.com
CC: openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
Devin, agree with you 100% that the EC2 and OS APIs are presentation/view
layer. I also think t
openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of George Reese
> Sent: 09 July 2011 07:49
> To: Sandy Walsh
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone instance ident
Devin, agree with you 100% that the EC2 and OS APIs are presentation/view
layer. I also think that there is way too much view/control and policy
dependencies buried down in the core nova-* services. The core services like
nova-compute shouldn't be using things like EC2 instance-id, instance-typ
On Jul 9, 2011, at 8:23 PM, Devin Carlen wrote:
> 1) Why are we even trying to have the same ID for an instance or image across
> two different APIs?
Even if we just pass back the first-8 with the EC2 API, it would be good if
there were some logical mapping so that somebody that works with Ela
Apologies but I've been lurking on this thread and I have to agree with Devin.
What I want from Openstack APIs is a consistent API that handles the provider
platform behind the scenes. In a scenario where i need to manage aws
separately, for instance, I may need openstack to expose native iden
On Jul 8, 2011, at 2:19 PM, Vishvananda Ishaya wrote:
> My hope was that turning ec2 into a compatibility api would force people
> adding the ec2 features to make them work in the openstack api as well. I
> really feel like we're failing in producing a cloud standard api if we don't
> have all
Here's a few crazy questions for you guys to consider:
1) Why are we even trying to have the same ID for an instance or image across
two different APIs?
2) How many people really switch back and forth between OpenStack and EC2 API
once they pick one?
3) How many people really expect euca2ools
But this cuts both ways: many of their clients don't immediately adopt new
changes, and if we can provide a spec for what parts of the amazon api you
have to stay within to obtain switch-ability with openstack, then we slow
down the adoption of those new features.
The clients that are happy with l
What if we wrote our own spec of the common features. Document the heck
out of anything where the amazon spec and implementation differ and follow
the implementation. Do to amazon what WS-I did to SOAP tools. Any fraction
of the market we can get perceiving value in the true interoperability
spec w
hpad.net
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
> worth the effort?
>
> On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote:
>>
>> Wow, really? Is EC2 really that sporadic/chaotic?
>>
>> I have to plead ignorance because I don
mment?
-S
From: Jorge Williams
Sent: Saturday, July 09, 2011 2:28 AM
To: Sandy Walsh
Cc: Soren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote:
>
> Wow
On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote:
>
> Wow, really? Is EC2 really that sporadic/chaotic?
>
> I have to plead ignorance because I don't know where the rubber meets the
> road, but that kinda surprises me.
I'm not saying that. In fact let me say that I don't think the Windows API
> -Original Message-
> From: Soren Hansen [mailto:so...@linux2go.dk]
> Sent: 08 July 2011 12:43
> To: Ewan Mellor
> Cc: Thorsten von Eicken; openstack@lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API -
> Is it worth the effor
From: Jorge Williams [jorge.willi...@rackspace.com]
> What you are proposing that we try to achieve with EC2 what the Wine folks
> want to achieve with the Windows API. It's a different problem. It's a much
> harder problem because it involves reverse en
On 7/8/2011 5:32 PM, Lorin Hochstein wrote:
I don't think that the OpenStack project should commit to maintaining
EC2 compatibility at all costs, only as long as the benefits outweigh
the development costs. In particular, if Amazon deliberately started
making changes to break the API, that woul
This ship may have sailed, but given what I have seen across a wide variety of
cloud APIs and what I are here, I strongly question the value of supporting an
EC2 API. I think you overestimate the value of supporting existing tools.
Sent from my iPhone
On Jul 8, 2011, at 19:32, Lorin Hochstein
+1
Devin
On Jul 8, 2011, at 10:29 AM, Lorin Hochstein wrote:
>
> On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote:
>
>> +1 to Soren's argument that ec2 is the 1000lb gorilla and should be central
>> to nova. We definitely need to support it with as close to 100%
>> compatibility as we can.
>
Stepping back for a moment, I think the two main benefits of supporting the EC2
API are:
- Leverage existing 3rd party tools that talk to EC2 API (e.g., euca2ools,
boto, Elasticfox/Hybridfox)
- Reduce the cost of switching to OpenStack for EC2 users
I agree with Soren that these benefits are lo
If the spec doesn't match the specification then they are admitting that they
have a bug. They broke the contract, we can lobby them to change it or write
an implementation that does the right thing. Or we should not be using the
spec at all. I'd much rather encourage clients to implement aga
HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were
developed and continue to be developed in the open -- and both clients and
servers (proprietary and open source) are very compliant to them. I'd like to
propose that our APIs take the same approach.
You are proposin
2011/7/8 Vishvananda Ishaya :
> Yes they seem to apply to all ids
> r-XXX
> ami-XXX
> i-XXX
> vol-XXX
> snap-XXX
>
> That said we are using base-36 for the hex in reservation ids and no one has
> complained, so i don't think they are used by the tools that much.
Not true. Elas
> From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
> [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
> of Chris Behrens [chris.behr...@rackspace.com]
> Sent: Friday, July 08, 2011 5:43 PM
> To: George Reese
> Cc: ; Ed Leafe; Chris Behre
kspace@lists.launchpad.net
> [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
> of Chris Behrens [chris.behr...@rackspace.com]
> Sent: Friday, July 08, 2011 5:43 PM
> To: George Reese
> Cc: ; Ed Leafe; Chris Behrens
> Subject: Re: [Openstack] Cross-zone
nchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Chris Behrens [chris.behr...@rackspace.com]
Sent: Friday, July 08, 2011 5:43 PM
To: George Reese
Cc: ; Ed Leafe; Chris Behrens
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth t
On Jul 8, 2011, at 6:06 AM, Soren Hansen wrote:
> 2011/7/7 Vishvananda Ishaya :
>> On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
>>> 2011/7/7 Trey Morris :
The goal isn't for ec2 api to be a "second class citizen", but to keep it
from being a limiting factor since we don't have contr
On Jul 8, 2011, at 5:11 AM, George Reese wrote:
> I would just like to re-iterate that I think the entire UUID approach is
> flawed and issues like this are one of the key reasons why.
The only problem I'm aware of is that developers using the EC2 API are not
adhering to the spec. If everyone
This is actually quite simple:
If your objective is to leverage existing tools written to the EC2 API, then
you build to the reality of the implementation, not the spec.
If your objective is to support the EC2 API as a de facto standard, then you
build to the specification.
On Jul 8, 2011, at
One thing that keeps coming up in this discussion is the issue of
"being tied to an API we don't control".
People... We're *fantastically* privileged that we get to define an
API of our own. Lots and lots and lots of people and projects spend
all their time implementing existing (open, but complet
2011/7/8 Ewan Mellor :
> If you believe that that's true, then we should get Amazon to redefine the
> EC2 spec to match the reality of what's in the field.
What would their motivation be?
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Develop
ten von Eicken; openstack@lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API -
> Is it worth the effort?
>
> 2011/7/8 Ewan Mellor :
> >> The whole point of supporting the EC2 API is to support people's
> >> existing tools an
2011/7/8 Jorge Williams :
> I'm with Ewan on this point: One of the nice thing about having a contract
> is that it clearly designates what's a bug and what isn't. If the spec says
> the ID is a string and the client assumes it's an integer, then the client is
> at fault. End of story. It w
2011/7/8 Jay Pipes :
> On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen wrote:
>> 2011/7/8 Ed Leafe :
>>> No, it would work more like: a new instance is requested, and the host
>>> selected. A candidate UUID would be generated and checked for "first 8"
>>> uniqueness (I had already added a db metho
+ 1
If the nova-* service APIs are all talking UUIDs, then there could be an OS-API
1.0 endpoint and an OS-API 2.0 endpoint coexisting on the same zone. Much of
the UUID disagreements are around exposing them to clients. So, support OS
API 1.0 interfaces that don't use UUID the same way as E
On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote:
> +1 to Soren's argument that ec2 is the 1000lb gorilla and should be central
> to nova. We definitely need to support it with as close to 100% compatibility
> as we can.
>
> Sounds like the only option is to "embrace and extend" it. Do everythi
s+sandy.walsh=rackspace@lists.launchpad.net
> [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
> of Jorge Williams [jorge.willi...@rackspace.com]
> Sent: Friday, July 08, 2011 12:01 PM
> To: Soren Hansen
> Cc: Ewan Mellor; openstack@lists.launchp
space.com]
Sent: Friday, July 08, 2011 12:01 PM
To: Soren Hansen
Cc: Ewan Mellor; openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
I'm with Ewan on this point: One of the nice thing about having a contract is
that it clear
On Fri, Jul 8, 2011 at 10:36 AM, Sandy Walsh wrote:
> So, instead of
>
> EC2 Client OS Client
> | |
> EC2 API OS API
> \ /
> [Service] API
>
> We'd be shifting to:
>
> EC2 Client EC2 API
> |
> OS Client -- OS API
>
I'm with Ewan on this point: One of the nice thing about having a contract is
that it clearly designates what's a bug and what isn't. If the spec says the
ID is a string and the client assumes it's an integer, then the client is at
fault. End of story. It would be a different issue if the c
Ugh ...
"... but at first blush, it doesn't seem like such a *bad* thing?"
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists
+1 to Soren's argument that ec2 is the 1000lb gorilla and should be central to
nova. We definitely need to support it with as close to 100% compatibility as
we can.
Sounds like the only option is to "embrace and extend" it. Do everything it can
do, and layer on what we need provided it doesn't
On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen wrote:
> 2011/7/8 Ed Leafe :
>> No, it would work more like: a new instance is requested, and the
>> host selected. A candidate UUID would be generated and checked for "first 8"
>> uniqueness (I had already added a db method to locate by the fi
2011/7/8 Ed Leafe :
> No, it would work more like: a new instance is requested, and the host
> selected. A candidate UUID would be generated and checked for "first 8"
> uniqueness (I had already added a db method to locate by the first 8 chars of
> a UUID across nested zones). When an acc
On Jul 8, 2011, at 8:02 AM, Soren Hansen wrote:
>> The code to use the first 8 chars of the UUID in the ec2 id was created and
>> working well, but discarded in favor of a more limited approach.
>
> Why?
It was felt that using UUIDs as the unique identifier only at zone
boundaries, and
2011/7/7 Vishvananda Ishaya :
> On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
>> 2011/7/7 Trey Morris :
>>> The goal isn't for ec2 api to be a "second class citizen", but to keep it
>>> from being a limiting factor since we don't have control over it. How does
>>> the compatibility layer make it
2011/7/8 Ewan Mellor :
>> The whole point of supporting the EC2 API is to support people's
>> existing tools and whatnot. If we follow the spec, but the clients
>> don't work, we're doing it wrong.
> True enough. However, in the case where we've got a demonstrated divergence
> from the spec, we s
> [Snip]
>
> The whole point of supporting the EC2 API is to support people's
> existing tools and whatnot. If we follow the spec, but the clients
> don't work, we're doing it wrong.
True enough. However, in the case where we've got a demonstrated divergence
from the spec, we should report that
2011/7/8 Ewan Mellor :
>> From Thorsten von Eicken
>> FYI, there's nothing in the EC2 API that limits instance identifiers
>> (or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to
>> add another digit when running out of 32-bit IDs.
> If that's the case (and I believe you, that
I would just like to re-iterate that I think the entire UUID approach is flawed
and issues like this are one of the key reasons why.
-George
On Jul 8, 2011, at 7:02 AM, Soren Hansen wrote:
> 2011/7/8 Ed Leafe :
>> On Jul 7, 2011, at 11:46 AM, Trey Morris wrote:
>>> If I had to choose between dr
2011/7/8 Ed Leafe :
> On Jul 7, 2011, at 11:46 AM, Trey Morris wrote:
>> If I had to choose between dropping or truncating UUIDs and failing feature
>> parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs
>> have already been discussed and decisions made. The EC2 api shouldn't
> From Thorsten von Eicken
>
> FYI, there's nothing in the EC2 API that limits instance identifiers
> (or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to
> add another digit when running out of 32-bit IDs.
If that's the case (and I believe you, that's always how I assumed i
On Jul 7, 2011, at 11:46 AM, Trey Morris wrote:
> If I had to choose between dropping or truncating UUIDs and failing feature
> parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have
> already been discussed and decisions made. The EC2 api shouldn't get in the
> way. A tr
On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
> 2011/7/7 Trey Morris :
>> The goal isn't for ec2 api to be a "second class citizen", but to keep it
>> from being a limiting factor since we don't have control over it. How does
>> the compatibility layer make it second class?
>
> Well, for one
2011/7/7 Trey Morris :
> The goal isn't for ec2 api to be a "second class citizen", but to keep it
> from being a limiting factor since we don't have control over it. How does
> the compatibility layer make it second class?
Well, for one thing because you'll be limiting the EC2 API to what the
Ope
1 - 100 of 110 matches
Mail list logo