From a Rackspace perspective, we do not want to expose block operations in the
compute API. The plan has been to expose the attach/detach as nova API
extensions, and that still makes sense, but will there be a separate,
independent block service and API?
Erik
From: Chuck Thier
To promote consistency across OpenStack APIs, I suggest we follow the same
model as in OS compute. That is, have a high level entity called /flavors.
One can query flavors to determine what types of volumes are available (based
on sla, performance tiers, whatever) then pass in the flavor ID
/. And going to make the merge proposal to
trunk.
Also we going to create blueprint about #3 and attach branch to it.
Eldar
On Sat, Apr 16, 2011 at 2:34 AM, Erik Carlin erik.car...@rackspace.com
wrote:
Eldar -
The OpenStack API already supports sharing IPs between instances (although
this may
Rick -
Agree with everything below. IMO, #3 should apply in general to all OS services
(core network, block storage, load balancing, etc.) We want things to work as
a suite of services but each service should be independent and deployable by
itself. There will obviously by interface
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,
service :-).
Thanks for asking and pushing for clarification.
Erik
From: Jesse Andrews anotherje...@gmail.commailto:anotherje...@gmail.com
Date: Tue, 1 Mar 2011 10:16:32 -0600
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc: Erik Carlin erik.car
John -
Are we just talking about compute aspects? IMO, we should NOT be exposing
block functionality in the OS compute API. In Diablo, we will break out block
into a separate service with it's own OS block API. That means for now, there
may be functionality in nova that isn't exposed (an
That all sounds good. My only question is around images. Is glance ready to
be an independent service (and thus have a separate API) in Cactus?
Erik
From: John Purrier j...@openstack.orgmailto:j...@openstack.org
Date: Mon, 28 Feb 2011 16:53:53 -0600
To: Erik Carlin erik.car
-0800
To: Erik Carlin erik.car...@rackspace.commailto:erik.car...@rackspace.com
Cc: John Purrier j...@openstack.orgmailto:j...@openstack.org,
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API for Cactus (critical!)
Erik,
Thanks
The way I see it, there isn't a singular OpenStack API (even today there is
swift, nova, and glance). OpenStack is a suite of IaaS each with their own API
– so there is a SUITE of standard OS APIs. And each OS service should strive
to define the canonical API for automating that particular
Whoops. Extension presentation link was broken.
Herehttp://wiki.openstack.org/JorgeWilliams?action=AttachFiledo=viewtarget=Extensions.pdf
is a working one.
From: Erik Carlin erik.car...@rackspace.commailto:erik.car...@rackspace.com
Date: Fri, 18 Feb 2011 16:32:30 -0600
To: Justin Santa
I would just call it VMDK. That's what Vmware
(http://www.vmware.com/technical-resources/interfaces/vmdk.html) and
everyone else calls it, even though there may be extra files to support
it. We're just naming the disk format here.
We had also talked about the IMG disk format to support AMIs but
Correct me if I am wrong, but I believe AMIs use IMG so that should be
another disk format a well (it would be the only one in the AMI appliance
format unless AWS changes it). Is there enough variance in the virtual
disk and envelope formats over time that we want to include version
columns or
We know Amazon is highly, highly elastic. While the instances launched
per day is impressive, we know that many of those instances have a short
life. I see Guy is now teaming up with CloudKick on this report. The EC2
instance ID enables precise measurement of instances launched, and
CloudKick
14 matches
Mail list logo
