With the excellent work going on in the emerging version for D6, are there plans to add support for Mosso/Rackspace's CloudFiles CDN?

According to their own words (OK, take a bucket of salt), it's a way better CDN than Amazon's CloudFront -- see http://blog.mosso.com/2009/02/a-quantitative-comparison-of-rackspace-and... and http://blog.mosso.com/2009/01/top-10-reasons-why-cloud-files-limelight-o...

(Sorry, I know 6.x dev exists now but it still does not appear in the version dropdown, so I've labelled this incorrectly.)

CommentFileSizeAuthor
#12 daemon.patch76.03 KBnestor.mata
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Title: Support for CloudFiles (Mosso/Rackspace) CDN? » [daemon] Support for CloudFiles (Mosso/Rackspace) CDN?
Version: 5.x-1.0-rc2 » 6.x-1.x-dev

Hm, weird, it appears for me. Maybe a cache issue? Or it's a d.o permission issue. Don't know. Let me know if it persists and I'll file an issue in the d.o issue queue.

And wow, are we moving fast or what? It seems somebody wrote a Django storage class for Mosso Cloud Files exactly one day ago! Amazing! So I've already posted back (http://code.welldev.org/django-storages/issue/8/mosso-cloud-files-storage) in the django-storages issue queue, reporting the existence and asking what the typical Django (or Python) policy is in these things.

If it works, it's about 15 minutes of work :)

Basically:
1) add cumulus.storage.CloudFileStorage to the daemon: dependencies.storages.MossoCloudFileStorage.MossoCloudFileStorage
2) write a thin transporter wrapper around it, like transporters.transporter_ftp.TransporterFTP, but then transporters.transporter_cloudfiles.TransporterCloudFiles

That's it. Note that this *only* requires changes in the daemon, not in the Drupal CDN integration module! But there's no issue queue for that yet, so until that exists, we'll abuse the d.o issue queue

Care to roll a patch? :) You'd be the first contributor (of hopefully many more)!

Wim Leers’s picture

So … only 10 days further … and it's been committed to django-storages! See https://bitbucket.org/david/django-storages/issue/8/mosso-cloud-files-st.... Rock on, open source!

I'll probably have enough time to incorporate this into the daemon as well.

Wim Leers’s picture

Title: [daemon] Support for CloudFiles (Mosso/Rackspace) CDN? » [daemon] Support for CloudFiles CDN?

I haven't had the time and I have to finalize my bachelor thesis text today. I will add this after my thesis defense though! :)

te-brian’s picture

Hate to just bump an issue, but I'm excited to see CloudFiles support in the daemon so I can give it a go. Please let me know if there is any support I can lend.

Wim Leers’s picture

Will be done ASAP :)

jnpWebDeveloper-1’s picture

Bump. I'd love to use this module with Mosso's cloud files. Any progress update?

nestor.mata’s picture

Great work!

I'll be looking for this cloudfiles implementation.
Thanks!!!

nestor.mata’s picture

I added the support to publish to Mosso Cloudfiles, I'm talking to Wim to hand him the changes so he can update the daemon.

Nestor

scotjam’s picture

Hi Nestor

Is the support to publish to Mosso something that can be applied as a patch? Or is it better to wait for an official update to the daemon?

best wishes
scotjam

Wim Leers’s picture

I'm waiting for Nestor's patch :)

nestor.mata’s picture

Status: Active » Needs review
FileSize
76.03 KB

Hi,

I created a patch over the changes I made.
Also the patch includes the cloudfiles library for python, I'm not sure if Win will want to add it or just keep instructions of how to download it.
Let me clarify that I'm not a python developer, so if you find something that can be improve it go for it. I based on some other files and what I was able to find out on the way.

modified transporters/transporter.py
added dependencies/storages/mosso.py
added transporters/transporter_mosso.py
added cloudfiles/*

To configure the destination use something like this in the configuration file:

  <servers>
    <server name="blog push cloudfiles" transporter="mosso" >
      <username>mymossoaccount</username>
      <api_key>mymossoapikey</api_key>
      <container>test_container</container>
    </server>
  </servers>

BTW, awsome work Win Leers, thanks a lot.

~Nestor

Wim Leers’s picture

Status: Needs review » Closed (won't fix)

I've moved the File Conveyor daemon to its own project at github: http://github.com/wimleers/fileconveyor. Please create a new issue there: http://github.com/wimleers/fileconveyor/issues.

Won't fixing it here.

Nestor, THANK YOU so much! :)

Wim Leers’s picture

Status: Closed (won't fix) » Fixed

I committed this already anyway, to prevent this from getting lost: http://github.com/wimleers/fileconveyor/commit/d7faa774d97f1269ba374346e....

Thanks again :)

Wim Leers’s picture

Status: Fixed » Active

OOPS, I was looking at the wrong issue! It's #567890: Config.xml example for S3 and Cloudfront transports that got fixed: http://drupal.org/node/567890#comment-2162166.

Looking at this patch right now though :)

Wim Leers’s picture

Status: Active » Fixed

Committed!

See the following commits: http://github.com/wimleers/fileconveyor/commit/1f85935389bd0e15a179fdfdb... and http://github.com/wimleers/fileconveyor/commit/fb5ba9d95a04b63c973ae4779.... First time using git and that's why there 2 commits: I made an error in the first commit.

Most of the changes you suggested, went in intact. I replaced some tabs by spaces and moved the "cloudfiles" directory into the "dependencies" directory. I also added the necessary information to README.txt about this new Transporter, as well as the corresponding license information. That's it!

Thanks again :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.