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 just
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, and if you
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 switch
First, y'all need to remember that it isn't just AWS... it's N systems that
back-end OS API over time.
Ewan, I understand your intent, but it is a bit myopic:
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
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.
Speak for yourself! I debug complex situations every day. Sure, I
2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com:
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
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:
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com:
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
2011/7/11 Eric Day e...@oddments.org:
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com:
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
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* control
Perhaps. That sometimes happens when trying to make a very nuanced point :-).
I spent a lot of time hacking at nova-compute and the schemas for the
heterogeneous instance types blueprint and noticed a lot of EC2-isms buried
down in the code. Even though I've been using the EC2 interface
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. The
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
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
Ahhh.. OK. The namespace is embedded in the instance ID depending on the type,
so it should be sufficient to:
GET /servers/instance uuid
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
On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote:
How is
nova-account-instance uuid
any different than:
----
Where // (or some subset of them) are reserved/regulated?
Nothing, if -- is a full UUID. If we
Eric,
I've heard this argument before, but I don't understand how account 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
+1
I think the work really lives with formalizing the contracts at the
nova.[service].api level and pushing the discrepancies into the respective
public API's.
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
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
On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
How is
nova-account-instance uuid
any different than:
----
Where // (or some subset of them) are reserved/regulated?
Nothing, if -- is a full UUID. If we compare to
swift,
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-account-instance uuid
any different than:
----
Where // (or some subset of them) are reserved/regulated?
Nothing, if
Won't an IPv6 address do that by it's very nature?
-S
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:
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 exact same
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, at
If you're referring to encoding zone information, yes it would. I was trying
to ask more generally as well. IPv6 would be a very good solution, IMO.
- Chris
On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote:
Won't an IPv6 address do that by it's very nature?
-S
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 should we just keep with the original /96 (::0) address?
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
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-service portability.
-C
On
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
[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
API?
2011/7/11 Ed Leafe ed.le...@rackspace.com:
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
Den 11/07/2011 19.08 skrev Brian Schott brian.sch...@nimbisservices.com:
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
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 ed.le...@rackspace.com:
On
-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 the effort?
From: Ewan Mellor
-Original Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
On Behalf Of Ed Leafe
Sent: 11 July 2011 16:39
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance
I agree that implementing a perfect EC2 simulator would be hard. We shouldn't
try and do that. We should have an EC2-compatible API for a sensible
feature-set, but we shouldn't try and add support for every new feature that
Amazon adds.
The value of this API is that EC2-compatible tools can
Brian, your two posts seem at odds with each other.
So, I've got this completely external view and possibly my own particular skew
on the vision for OpenStack... specifically, I want it to isolate me from
provider as much as possible. Either I'm going to use AWS compatible
interfaces for a
Ok, so let's look at this from another perspective ... how far away are we?
I thought our EC2 binding was pretty good (admittedly, I don't use it).
Are we radically out in left field or is this a game of inches?
Any hardcore EC2 users care to comment?
-S
The other piece of the puzzle is that it is very easy to keep a client
consistent with the API; it's very hard to keep an implementation up-to-date.
I've built an EC2 compatible API and the problem is that understanding what has
changed in the API (and it changes fairly frequently) is hard. On
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
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
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
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 of
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
2011/7/8 Ed Leafe ed.le...@rackspace.com:
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
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 ed.le...@rackspace.com:
On Jul 7, 2011, at 11:46 AM, Trey Morris wrote:
If I had to
2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com:
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
[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/7 Vishvananda Ishaya vishvana...@gmail.com:
On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
2011/7/7 Trey Morris trey.mor...@rackspace.com:
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
2011/7/8 Ed Leafe ed.le...@rackspace.com:
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
On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen so...@linux2go.dk wrote:
2011/7/8 Ed Leafe ed.le...@rackspace.com:
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
+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
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 :
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
I don't think this is a technical issue, it's a business issue. If we want
adoption, we have to reduce switching friction. Sadly, this means EC2
bugs/nuances and all.
The better a job we do of this, the easier it will be for users to transition
from EC2 to OpenStack and benefit from all the
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 everything it
2011/7/8 Jay Pipes jaypi...@gmail.com:
On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen so...@linux2go.dk wrote:
2011/7/8 Ed Leafe ed.le...@rackspace.com:
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
2011/7/8 Jorge Williams jorge.willi...@rackspace.com:
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
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.
Ewan.
-Original Message-
From: Soren Hansen [mailto:so...@linux2go.dk]
Sent: 08 July 2011 05:40
To: Ewan Mellor
Cc: Thorsten von Eicken;
2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com:
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 |
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
Isn't there a concern of leaking internal Zone information to the outside world
(particularly in the Service Provider model)? If so, we're back to the mapping
table.
And, when multi-instance boot commands are more common (provision me 10
servers vs. 1), then more people will be searching by
Yeah, I'm not sure *how much* of the zone information would be sensitive,
though. Ie, is it okay to expose a unique identifier and nothing more? Or do
we want to expose _nothing_?
- Chris
On Jul 8, 2011, at 2:28 PM, Sandy Walsh wrote:
Isn't there a concern of leaking internal Zone
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.
Vish
On Jul 8, 2011, at 2:28 PM, Sandy Walsh wrote:
Isn't
2011/7/8 Vishvananda Ishaya vishvana...@gmail.com:
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.
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
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
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
+1
Devin
On Jul 8, 2011, at 10:29 AM, Lorin Hochstein lo...@isi.edu 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
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
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
-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 effort?
2011/7/8 Ewan Mellor
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
2011/7/7 Jay Pipes jaypi...@gmail.com:
Multiple zones is currently only supported in the OpenStack API, and
the question has been raised whether effort should be expended to get
parity in the EC2 API for this. The problem with the EC2 API is that
we do not have control over the instance
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.
TvE
On 7/7/2011 7:57 AM, Soren Hansen wrote:
2011/7/7 Jay Pipes jaypi...@gmail.com:
Multiple
Yes the issue isn't the actual api definition, the issue is that most of the
ec2 clients expect the exact format that amazon currently uses ami-8 hex
chars.
I think we should move toward ec2 being a compatibility layer that is
translated into the os api. This compatibility layer would sit at
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 translation layer to sit in between the EC2 and OS APIs would
2011/7/7 Vishvananda Ishaya vishvana...@gmail.com:
I think we should move toward ec2 being a compatibility layer that is
translated into the os api. This compatibility layer would sit at the top
level zone and could maintain its own database for conversion of ids,
management of secret and
On 7/7/2011 8:53 AM, Soren Hansen wrote:
2011/7/7 Vishvananda Ishaya vishvana...@gmail.com:
I think we should move toward ec2 being a compatibility layer that is
translated into the os api. This compatibility layer would sit at the top
level zone and could maintain its own database for
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?
On Thu, Jul 7, 2011 at 10:53 AM, Soren Hansen so...@linux2go.dk wrote:
2011/7/7 Vishvananda Ishaya
2011/7/7 Trey Morris trey.mor...@rackspace.com:
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
On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote:
2011/7/7 Trey Morris trey.mor...@rackspace.com:
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?
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
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 it
Hey all,
Recently, Nova added support for multiple zones in the OpenStack API.
Using the nova-manage tool, you can get a list of instances in a
single zone or in multiple zones using the --recurse option. When just
querying a local zone's API server, the listed instance identifiers
will be
Agreed.
That's the downside of not having control of an API. Unless we do the Embrace
and Extend thing, but that just seems fraught with problems if Amazon should
zig when we zag.
That said, top-level Zones may still operate using EC2 API, but all child-zones
may be OS-API. We'd only need
86 matches
Mail list logo
