>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 mailto:cth.
With the proliferation of new openstack services being built, is there any
reason not to use UUID as the standard resource ID format?
Erik
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individ
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 du
://yum.griddynamics.net/. 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
> wrote:
>> Eldar -
>>
>> The OpenStack API
Eldar -
The OpenStack API already supports sharing IPs between instances (although
this may be an extension?). What exact behavior are you after? More
important than the way in which we expose via the API is how it's
implemented. It's important to note that this is extremely network
topology de
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 standards
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
et all that from the word "service" :->).
Thanks for asking and pushing for clarification.
Erik
From: Jesse Andrews mailto:anotherje...@gmail.com>>
Date: Tue, 1 Mar 2011 10:16:32 -0600
To: Paul Voccio mailto:paul.voc...@rackspace.com>>
Cc: Erik Carlin mailto:erik.car..
Thanks Devin for the reiteration. I'm for EC2 API support, I just think that
OS owning our own API specs is key if we are to innovate and drive open,
standard per service interfaces.
Erik
From: Devin Carlen mailto:devin.car...@gmail.com>>
Date: Mon, 28 Feb 2011 19:59:38 -0800
To:
ce we complete the gap analysis John has
requested, these connections should become more clear.
Erik
From: Devin Carlen mailto:devin.car...@gmail.com>>
Date: Mon, 28 Feb 2011 17:44:03 -0800
To: Erik Carlin mailto:erik.car...@rackspace.com>>
Cc: John Purrier mailto:j...@openstack.o
That depends on what "near" means? This will no doubt have significant
network implications and I can envision at least two levels of near (for
Rackspace):
1. Same public subnet, whatever that translates to. This is what
Rackspace needs now and specifically for compute.
2. Same private network a
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 mailto:j...@openstack.org>>
Date: Mon, 28 Feb 2011 16:53:53 -0600
To: Erik Carlin mailto:erik.car...@rackspa
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 art
Whoops. Extension presentation link was broken.
Here<http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=view&target=Extensions.pdf>
is a working one.
From: Erik Carlin mailto:erik.car...@rackspace.com>>
Date: Fri, 18 Feb 2011 16:32:30 -0600
To: Justin Sant
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 ser
My understanding is that we want a single, canonical OS network service API.
That API can then be implemented by different "service engines" on that back
end via a plug-in/driver model. The way additional features are added to the
canonical API that may not be core or for widespread adoption (
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 wou
Totally agree with you Jorge, although I don't like the term "Dev APIs" (since
developers who consume the service will interact with the Public APIs). I
propose we call them Internal APIs.
Erik
From: Jorge Williams
mailto:jorge.willi...@rackspace.com>>
Date: Wed, 5 Jan 2011 05:00:56 +
To:
inter-cloud communication
>versus
>the overhead of a larger singular management domain.
>
>Bret Piatt
>OpenStack.org
>Twitter: @bpiatt / Mobile 210-867-9338
>Open Source Cloud Infrastructure: http://www.openstack.org
>
>
>
>-Original Message-
>From: openstack-bo
are talking about a single availability
>zone.
>
>On 12/30/2010 11:25 AM, Erik Carlin wrote:
>> You are right. The 1M number was VMs not hosts. At least, that was
>>from
>> one scale discussion we had within Rackspace. I'm not sure what the
>> "official
Jay -
Few comments below...
Erik
On 12/30/10 10:43 AM, "Jay Pipes" wrote:
>On Wed, Dec 29, 2010 at 2:27 PM, Erik Carlin
>wrote:
>> We know Amazon is highly, highly elastic. While the instances launched
>> per day is impressive, we know that many of those in
st servers, resize server,
etc. - granted, some are more expensive than others)
That works out to ~21K/hr but it won't be evenly distributed. To allow
for peak, I would say something like 75K/hour or ~21/sec.
Thoughts?
Erik
On 12/30/10 9:20 AM, "Pete Zaitcev" wrote:
>On W
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 pr
I love the idea of reusable libraries across OpenStack projects. That does
imply a common language, which may not always be the case, but it does
provide some dedup.
I do think each service should have language bindings. We have debated the
idea of a single set of language bindings across servic
25 matches
Mail list logo
