libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomaz Muraus <to...@cloudkick.com>
Subject Re: [libcloud] libcloud storage API proposal & ideas
Date Tue, 25 Jan 2011 00:34:30 GMT
I have worked on the Storage API a bit today and yesterday and mostly got a
"prototype" working - https://github.com/Kami/libcloud/commits/storage_api.

The code is far from finished, but imo it's a good start and it should be a
lot easier to talk about it when we have at least a partial implementation
here.

The important files are:

- Base class - http://s.apache.org/wP
- Reference implementation and CloudFiles Driver -
http://s.apache.org/7f0<https://github.com/Kami/libcloud/blob/170ebfef05d1b6596bdb0c580e28d86922ec94ff/libcloud/storage/drivers/cloudfiles.py>
- Exceptions, etc. - http://s.apache.org/C6H

Since I have been working on a reference implementation for the CloudFiles
driver, it's possible that some of the methods / arguments are biased
towards it and should be modified / removed.

So, like I have said, there are still a lot of things to do:
- Better error handling and making some parts of the code more robust
- RawResponse should really be named RawRequest / Request and a better part
of the codes which deals with the requests / response refactored -
http://s.apache.org/Tp6
- Refactoring and renaming some parts of the code
- Moving utility functions to a separate module (libcloud/util.py?)
- Actually separating the library into two parts - compute & storage (this
will require a lot of moving around and changes so I have planned to do this
on the end)
- DummyDriver (will work on this tomorrow)
- demo, examples
- update documentation
- ...

I will push the code to a separate branch to the libcloud repository
tomorrow so others can work on it as well.

Thanks,
Tomaz

On Mon, Jan 24, 2011 at 5:48 PM, Grig Gheorghiu <grig.gheorghiu@gmail.com>wrote:

> I just stumbled on this blog post which talks about a common for cloud
> data storage and management: CDMI. Not sure how legit this all is, but
> the guy who wrote the blog post works for NetApp.
>
>
> http://intotheinfrastructure.blogspot.com/2009/12/reference-architecture-for-cloud.html
>
> If this turns out to have industry support (and the SNIA member
> directory does have a lot of big hitters
> http://www.snia.org/member_com/member_directory/), then maybe
> libcloud's storage layer should adhere to the CDMI interface -- or at
> least provide an API for CDMI-compliant cloud storage solutions?
>
> Grig
>
> On Thu, Jan 13, 2011 at 10:41 PM, Sengor <sengork@gmail.com> wrote:
> > Depreciation warnings for starters, and it'd not be hard to port
> > existing code to a new libcloud version with proper upgrade
> > guidelines.
> >
> > It's probably as simple as %s/import\ libcloud/import\ libcloud.compute/
> >
> >
> > On Wed, Jan 12, 2011 at 7:06 AM, Tomaz Muraus <tomaz@cloudkick.com>
> wrote:
> >> Yeah, trying to still keep the old imports to work and just throwing a
> >> DeprecationWarning in the next few versions sounds ok.
> >>
> >> On Tue, Jan 11, 2011 at 7:54 PM, Paul Querna <paul@querna.org> wrote:
> >>
> >>> One question not posed is the module name.
> >>>
> >>> ie, should it all be inside libcloud.storage?
> >>>
> >>> This would imply moving all our existing code to libcloud.compute,
> >>> which is kinda a pain for upgrades, but I'm kinda a fan of maybe doing
> >>> it for 0.5, but having the old imports work too for a few versions.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>>
> >>> Paul
> >>>
> >>>
> >>> On Tue, Jan 11, 2011 at 7:30 AM, Tomaz Muraus <tomaz@cloudkick.com>
> wrote:
> >>> > Hello all,
> >>> >
> >>> > I have posted a short proposal / ideas for the object storage API on
> the
> >>> > libcloud wiki - http://wiki.apache.org/incubator/LibcloudStorageAPI
> >>> >
> >>> > Please post your feedback, opinions and ideas how to improve it.
> >>> >
> >>> > I think the next step after deciding how the API should look like (at
> >>> least
> >>> > approximately) should be
> >>> > implementing the base API and creating a reference driver and then
we
> can
> >>> > move on from there :-)
> >>> >
> >>> > - Tomaz
> >>> >
> >>>
> >>
> >
> >
> >
> > --
> > sengork
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message