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 makes a lot of sense.
Alex On Sat, Jun 29, 2013 at 3:29 AM, John Carr <[email protected]> wrote: > 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 > > -- "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
