New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no region support #16
Comments
Patches welcome. I probably won't have any free time to fix this in the coming month or two. |
I will likely patch. I just wanted to get the ticket open in case you already had a fix. |
That's always a good thing. If the patch is accompanied with tests I'd be happy to merge it. |
tests and docs where appropriate. yes sir. But not today. |
I finally sat down to do this and discovered it's a much bigger change than I'm prepared to write. I'm really not very good at moose, so I don't feel comfortable designing the upgrade to API v2.0 under your namespace... When you auth in the v1.0 fashion, like you do in the module... you only get one storage url. When you auth v2.0 style, you get a JSON list of endpoints to choose from. Some are ORD, some are DFW. http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/curl_auth.html I'd still like to help, but I need feedback to proceed from here. |
I'll try to look into it soon. I'm currently swamped with work so it can be a couple of weeks. I think when constructing the object you should be able to provide the endpoint. When authenticating it fetches the list of available endpoints and at that point I think it should validate if the provided endpoint is valid. |
I kinda went my own way. I'm not convinced yet that I'll release my module on the CPAN, as it seems rude to reinvent the wheel, but I wanted a module that was designed very different from the guts to the glory. I may yet release and just point to your modules from the see also. But besides that. The main problem that stopped me from hacking was the authentication. You can't get a list of the endpoints (and I'm not sure they need to be validated since they come from the API directly) without using the version 2 auth and you're suite isn't set up for the JSON response or anything about the request/reply. It won't take much hacking, but since I've never really used moose and have been meaning to get around to learning it for like 7 years without bothering, it's clear I'm not the right guy to hack it into what you built. But needing something really soon, I just wrote my own moose-less suite. |
Sorry for the late response. There's no harm in releasing a module on CPAN that more or less does the same thing as an existing module. Please do release it if you feel like others can benefit from it. Personally I wished this module wasn't written in Moose either, but I inherited it and I lack the time to rewrite it using something like Moo. |
Any update on this issue? I'd love to see it fixed! I'm not sure if I feel comfortable changing the code base either, as I don't even see where the DFW issue is being created. |
Hi, I had forgotten about this issue. As you might've guessed I'm still swamped with work. So to help me save some time to figure this stuff out myself, what do you mean with DFW? The link at the top of the page no longer works... Is the region simply a parameter you can add during authentication? If so, all that would need to be added is an extra field that stores the region, which can be used during authentication. |
Here is an updated link that works: https://support.rackspace.com/how-to/multi-region-support-in-cloud-files/ I have this problem too. CyberDuck works... maybe they can contribute their patch? |
Thanks for the added information. I'm no longer maintaining this module though. So if anyone else wants to take over I'd be happy to transfer the maintainer rights. |
http://docs.rackspace.com/files/api/v1/cf-devguide/content/Multi_region-dl2200.html
My containers are all ORD, and this is always choosing DFW.
The text was updated successfully, but these errors were encountered: