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 prettier for us libcloud contributors, but makes code that uses libcloud more annoying. (3) loses some points because I would have to instance a second Driver class with almost the same arguments and somehow pass that to the helper methods on the compute Node or to the compute driver itself. That isn't very elegant. Anything but the most light integration would probably lead to abstraction leakage. (And I can see users managing block storage too, without thinking of compute nodes, but I just think it should be through the compute driver. I don't think we should get hung up on taxonomy, block storage and S3 are different beasts.) Cheers, John On 29 Jun 2013, at 04:16, Chris Psaltis <[email protected]> wrote: > 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
