On Thu, Jun 27, 2013 at 3:00 AM, Tomaz Muraus <[email protected]> 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.
>
>
Ok (I wrote this without checking the class names apparently).


> 2. As far as line 16 goes - Imo, having a separate method makes it more
> explicit and easier for developers if a provider doesn't support
> snapshotting.
>
> In this case, developer doesn't need to do anything and driver will
> automatically throw "not implement error" if a user calls
> "snapshot_create_volume" method and this method is unimplemented.
>
> In case of an argument to the create_volume method, developer will need to
> define a method without a "snapshot" argument.
>
> I think that's fine, but I would imagine most of the developers will just
> copy the base API and leave "snapshot=None" argument there and just ignore
> it if a user passes it to the method. Imo, that's confusing to the end
> user.
>
> 3. Heh, Jed already said some method names are wordy, but I personally like
> "create_volume_from_snapshot" more than "snapshot_create_volume".
>
> I'm not to opinionated about this one and I'm totally fine going with
> "snapshot_create_volume" if more people think it's better though.
>
>
I don't have a particular opinion, I would probably always write
`snapshot.create_volume()` anyways.


> 3. How do we plan to integrate this with the compute API? Do we even plan
> to do it?
>
> I think there is value in adding some integration with the compute API and
> some of the existing compute drivers already expose methods for managing
> block storage: For example:
>
> 1.
>
> https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/gandi.py#L369
> 2.
>
> https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/cloudstack.py#L429
>
> A couple of drivers implement read-only functionality (e.g. list_volumes)
> and a couple of other drivers implement full CRUD functionality using
> extension methods.
>

I think there should be some integration, I'm not sure how much (maybe it
will become clearer once I start implementing)?


>
> 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

Reply via email to