Jurgen Goedbloed <jurgen@...> writes: > > I had a brief look at the code for cloudfuse but it looks "interesting" > with stdio fopen etc. I got the feeling that libdroplet looks more > promising but who knows some people come up with better alternatives a > search of github and sourceforge doesn't show much for old school > programming languages. > (Most is for Python and although we support plugins in Python that > doesn't work for storage plugins and its also not the way I want to > take it now so I would opt for a native C or C++ library.) > > Although I'm not a developer and have very little knowledge of writing > code, I'd be happy to help the discussion and do some testing. So, to > start.. any comments? Not quite the enormous discussion I had hoped to get but we are still a starting community and restarting a dead development community is hard.
Some updates on where we are as of today. We just pushed some commits to the nightly master branch that adds support for 3 currently highly experimental storage backends. e.g. - GlusterFS using gfapi. - CEPH using librados. - S3/Swift using a somewhat hacked version of libdroplet. As I already said we eventually settled for libdroplet to interface to the S3 and Swift environments. It still has some problems and we forked it to try to fix at least the first roadblocks. We plan on upstreaming the patches and work with the guys at Scality to make it more robust and better usable for Bareos. Its also still seriously experimental we did the first tests with GFAPI and Gluster that seems to work well but we need to figure out the obvious things like blocksize, spooling etc in combination with these new features. For droplet I tested with the POSIX backend which allows you to write things locally (which saves you some money not to have to send it to Amazon etc.) We are also setup now for a free Amazon account and we got an internal RIAK-CS S3 storage which we are doing the first tests with to get libdroplet and droplet-sh working with it. We also need to package some stuff so that is currently also a focus we for Linux at least want to provide rebuild stuff for libdroplet and droplet-sh so you can setup and test your object storage and make sure it works before point the bareos driver at the config you created. If you want to give it a spin you can try it notice that its positioned as secondary storage e.g. you should backup to disk and then do copy or migration jobs to the cloud or directly to the cloud if you want to live dangerously. Also be aware if you use a paying service it may not currently do the most wanted and cost optimized way of sending the data to the cloud. When using it with some internal cloud you should really ask yourself when its CEPH or Gluster based if you not rather use the native APIs. The README.md file on github gives the current status of things which may change over the next couple of weeks. People interested in testing CEPH storage or GFAPI can use the following information as the first steps in setting up things. Its mostly the same as setting up a file storage device only you set the devicetype e.g. gfapi, rados or object and you need the right devel packages for the apis. The archive device tells the different drivers how to behave for gfapi that is an URI which is more or less the same as what qemu uses for gfapi access e.g. somethings like gluster[+transport]://[server[:port]]/volname[/dir][?socket=...] e.g. Device Type = gfapi Archive Device = gluster://localhost/volname For object storage (S3/Swift) you point to a libdroplet profile (See https://github.com/scality/Droplet) and then a bucketname e.g. Device Type = object Archive Device = /home/mvw/.droplet/default.profile:<bucketname> Keep in mind that S3 is mostly there in libdroplet, swift is somewhat more experimental they are missing some things for storing acls and extended attributes but given we don't use those I think it should mostly work. For rados (which only compiles :-)) its rados_configname:<poolname> e.g. Device Type = rados Archive Device = /home/mvw/rados_cfg:<poolname> We also merged today some blocksize patches which might come in handy in combination with this new storage backends. Things also have to go through regressions the coming days and it seemed to work fine today it no guarantee that in the process of making things more generic usable we didn't break anything. -- Marco van Wieringen marco.van.wierin...@bareos.com Bareos GmbH & Co. KG Phone: +49-221-63069389 http://www.bareos.com Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Komplementär: Bareos Verwaltungs-GmbH Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens, P. Storz, M. v. Wieringen -- You received this message because you are subscribed to the Google Groups "bareos-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to bareos-devel+unsubscr...@googlegroups.com. To post to this group, send email to bareos-devel@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
