From the options offered by Tomaz:
1. Keep the existing API which is coupled to the compute API, iterate
on it
/ improve it if necessary
2. Add a new, top-level Block Storage API, remove existing block
storage
related methods from the compute API
3. Add a new, top-level Block Storage API and update existing block
storage
related methods on the compute API to call into methods on the new top
level Block Storage API
Option (3), although more complicated, seems to be the best one.
I'll use AWS terminology to illustrate my point. EBS is about storage
and clearly belongs to the storage drivers, like S3. In terms of usage,
I can imagine people listing EBS volumes, deleting them etc without even
bothering about the nodes to which these volumes are attached to. On the
other hand, I can also imagine someone trying to do
node.detach_volume(), node.attach_volume(), node.create_snapshot() etc.
In this sense I think option 3 is the best one because it deals with
both use cases.
This does come with maintainability issues though. If I had to choose
from the other 2, I'd go with the a new top level API. This way you can
deal with list_volumes() and juggle your way around attach/detach with
something like volume.attach_to_node(node).
Tomaz offers is best suited in this case. Initially it seems
On 2013-06-28 19:45, Alex Gaynor wrote:
So the biggest missing piece from the existing block-storage APIs that
I
see is snapshotting (Creation from a volume, creating a new volume
from a
snapshot, listing, and deletion). I don't have a good sense of whether
they
make the compute driver "too big" or whether it's fine to just add
them.
What do other people think?
Alex
On Fri, Jun 28, 2013 at 9:39 AM, Tomaz Muraus <[email protected]>
wrote:
Yeah.
I also think there is some merit in having Block Storage as an
additional,
separate top level API. It's been a while since I've last researched
all
the existing block storage APIs so I would need to research it again
to
refresh my memory, but I would also be interested in hearing other
people's
take on it.
From this perspective, we have the following options:
1. Keep the existing API which is coupled to the compute API, iterate
on it
/ improve it if necessary
2. Add a new, top-level Block Storage API, remove existing block
storage
related methods from the compute API
3. Add a new, top-level Block Storage API and update existing block
storage
related methods on the compute API to call into methods on the new
top
level Block Storage API
Alex, since you've done this research fairly recently, what's your
take on
this?
On Fri, Jun 28, 2013 at 6:23 PM, Alex Gaynor <[email protected]>
wrote:
That looks fine to me (I see only a few drivers implement it). I
guess
this
means we'd move all the methods from a new set of drivers onto
compute?
Alex
On Fri, Jun 28, 2013 at 9:19 AM, Tomaz Muraus <[email protected]>
wrote:
Heh, so it turns out I totally forgot that Libcloud already defines
a
limited API for managing block storage:
*
https://github.com/apache/libcloud/blob/trunk/libcloud/compute/base.py#L368
*
https://github.com/apache/libcloud/blob/trunk/libcloud/compute/base.py#L705
Current block storage API is pretty tightly coupled to the compute
API,
but
it's pretty similar to what Alex proposed so we can probably use it
as
a
good starting point.
Alex - what do you think?
On Thu, Jun 27, 2013 at 12:16 AM, Alex Gaynor
<[email protected]>
wrote:
Hi all,
I'm interested in adding block storage support to libcloud (for
the
providers that suppor it of course). To that end, I've drawn up a
simple
design for the driver and related classes for the features that
seem
to
be
supported generally (I reviewed Rackspace and Amazon).
You can find the design here:
https://gist.github.com/alex/5872132,
I
think
it's mostly self-explanatory and consistent with the rest of
libcloud,
as
well as the (thankfully consistent!) terminology used by the
providers.
Let me know what you think, and if there's general interest I'll
go
ahead
and start working on implementations for a few providers!
Alex
PS: In the interest of full disclosure, I work at Rackspace and
have
a
bunch of work time to help make libcloud awesome!
--
"I disapprove of what you say, but I will defend to the death your
right
to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
--
"I disapprove of what you say, but I will defend to the death your
right
to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
--
mist.io
cloud management in your pocket
