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