On Jul 2, 2013, at 8:26 AM, Alex Gaynor
wrote:
> I think I've been swayed to favor (1) (putting it on compute drivers). a)
> it limits the code churn, which is nice, b) it's obvious they need *some*
> integration with each other, and there aren't well established patterns for
> that right now, r
I think I've been swayed to favor (1) (putting it on compute drivers). a)
it limits the code churn, which is nice, b) it's obvious they need *some*
integration with each other, and there aren't well established patterns for
that right now, rather than invent something new, grouping them together
ma
In order i'd probably vote 1, 3, 2.
For me, the guide is "how does the user express this in as few lines of code as
possible" and "how does the user express this elegantly".
So I am absolutely convinced the compute driver needs to be aware of block
storage. I think that (2) makes the code prett
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
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.
Wha
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 peopl
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 wrote:
> Heh, so it turns out I totally forgot that Libcloud already defines a
> limited API fo
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 pr
On Thu, Jun 27, 2013 at 3:00 AM, Tomaz Muraus wrote:
> Cool.
>
> I have some comments and questions:
>
> 1. We should probably get rid of the "Base" suffix.
>
> All of the bases API interfaces (libcloud.compute.base, libcloud.dns.base,
> libcloud.storage.base, etc.), don't contain this suffix.
>
On Wed, Jun 26, 2013 at 8:01 PM, Jed Smith wrote:
> This looks great, Alex! I haven't studied intently, but I have a
> couple quick comments:
>
> Line 16: Yes, I think it should be a parameter on create_volume. That
> makes the implementation less awkward if a provider does not support
> snapshot
Cool.
I have some comments and questions:
1. We should probably get rid of the "Base" suffix.
All of the bases API interfaces (libcloud.compute.base, libcloud.dns.base,
libcloud.storage.base, etc.), don't contain this suffix.
2. As far as line 16 goes - Imo, having a separate method makes it mo
Oh, and, without a doubt the mount point behavior was the single most
confusing thing about Amazon's API. I worry about that being a string,
but there is basically no other solution. Will be interesting to see
how this can be made to support attaching to Windows instances, as
well...
--
Jed Smith
This looks great, Alex! I haven't studied intently, but I have a
couple quick comments:
Line 16: Yes, I think it should be a parameter on create_volume. That
makes the implementation less awkward if a provider does not support
snapshotting.
Line 70: What does node= do on detach()? Is it a sanity
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 d
Cool, keep us posted and let us know if you need help.
On Thu, Jul 12, 2012 at 3:24 AM, Aymeric Barantal wrote:
>
> Le 12 juil. 2012 à 09:05, Tomaž Muraus a écrit :
>
> > list_volumes() sounds reasonable to me. Next step would
> > be researching existing provider APIs and see if most of them sup
Le 12 juil. 2012 à 09:05, Tomaž Muraus a écrit :
> list_volumes() sounds reasonable to me. Next step would
> be researching existing provider APIs and see if most of them support this
> functionality. If they do, we can then work on implementing those methods.
I started implementation of this Vo
list_volumes() sounds reasonable to me. Next step would
be researching existing provider APIs and see if most of them support this
functionality. If they do, we can then work on implementing those methods.
On Wed, Jul 11, 2012 at 2:58 AM, Alex Amies wrote:
> This is a big step forward but I thin
This is a big step forward but I think that we are missing a list_volumes()
method. It is important to me and seems inconsistent that LinCloud has
create and delete methods for storage volumes without at way to find out
what has been created.
I would like to propose a new method to the NodeDriver
> Overall the API you proposed looks pretty solid to me. Next step would be
> implementing this API for at least two providers. When coding a new API we
> require user to implement it for at least two providers so the
> implementation is not biased towards a single one.
>
> I also closed the old ti
Hi Tomaz,
A small question on your comment about the naming of the
"create_volume" method inline below:
>>
>> # The following methods could be added to
>> libcloud.compute.base.NodeDriver:
>>
>> def create_volume(**kwargs):
>> [SNIP]
>
>
> To be consistent with other method names it should jus
> Overall the API you proposed looks pretty solid to me. Next step would be
> implementing this API for at least two providers. When coding a new API we
> require user to implement it for at least two providers so the
> implementation is not biased towards a single one.
>
> I also closed the old ti
Hi Gabriel,
My replies are in-line.
On Wed, Jun 13, 2012 at 4:59 AM, Gabriel Reid wrote:
> Hi,
>
> I'd like to propose the addition of block-level storage volume management
> in LibCloud. In the two environments that I'm familiar with (Amazon EC2
> EBS and
> Cloudstack volumes), the way of worki
Hi,
I'd like to propose the addition of block-level storage volume management
in LibCloud. In the two environments that I'm familiar with (Amazon EC2 EBS and
Cloudstack volumes), the way of working is very similar, with the main
operations being:
- create storage volume
- attach storage vo
23 matches
Mail list logo
