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
[OpenStack] Decode body to array #2578
Conversation
I wonder what is causing this. What version of Excon are you using? |
|
@Bugagazavr I am trying to determine if this issue is just with the code you patched or if it is a much larger problem. When I try to retrieve a list of directories with my openstack instance along with the latest fog master and excon 0.31.0, I am not experiencing an issue. What version of ruby are you using? |
|
I am using 1.9.3. Let me give that a shot. |
@krames
when im use fog from master or rubygems and start precompile assets for rails ( asset_sync )
Maybe this selectel problem? |
Maybe. Let's try one more thing. Can you add |
@krames i put all excon debug to gist https://gist.github.com/Bugagazavr/8446663#file-fog-txt |
Looking at your response it does seem like OpenStack is responding appropriately:
I suspect this might be caused by something in your environment. Can I see your |
@Bugagazavr I tried to use your Gemfile to pull down your configuration and I am having problems with rails
@geemus I am having problems trying to duplicate @Bugagazavr's problem. It doesn't make sense to me that you would have to JSON decode Excon response data. Any idea what's going on here? Should we merge this or do you think this could be an environmental problem? |
@krames I think this is rails 4.1, because json reworked in this version ( where I heard it? ). |
@Bugagazavr have you experienced any other issues using fog with rails 4.1? |
@krames no, only OpenStack issue |
@geemus I was not able to duplicate this issue, but because this is a benign change I am inclined to merge it. What do you think we should do here? I do think there is a bigger issue that is going to resurface it's head at some point though. |
@krames the request method itself should do this decode. At a guess, I'd say the response we are getting here doesn't match |
@Bugagazavr Based on @geemus comment I took another look at the json decoding and I noticed that your context-type is being returned as My second thought is that it might be something wrong with your json library. Can you execute the following gist and send me the results? |
I would like to try one more thing. Can I get you to require this patch and then provide me with a gist of the output of code? Thanks for your help on this! |
Interesting!! I was expecting to see something output for type here. That would read me to believe that there is something wrong with the regular expression on this line. I did notice in that your content-type is coming back as I updated my gist to include more debugging information around the regular expression. Can I get you to re-run it and send me the output? Just so you know I am looking for an output like this:
|
@krames https://gist.github.com/Bugagazavr/8580140
|
Try adding an accept header to your curl command |
|
Looking back at both your curl commands, I do see content-type in both of them. So I think Selectel is returning the right data. My current thought is that we need to revise the regular expression on this line. I threw a couple different variations of the regular expression in my updated patch. Do you want to run that or play around with the regular expression yourself to get it properly work? |
@krames ok im test it, maybe use:
|
@krames hey, in your code you are looking for |
@geemus Thanks for the tip! Let me update the gist accordingly. |
@Bugagazavr I updated my patch based on @geemus suggestion. Let's see if this works any better. |
@krames yeah it works
|
@Bugagazavr excellent!! Do you want to revise your PR to use get_header? Or do you want me to create a new PR with the fix in it? |
@krames i send fix in my PR. Need rebase commits? |
@Bugagazavr Thanks! It would be nice if you would rebase, but it's not necessary. |
* 'master' of github.com:fog/fog: (58 commits) make disassociate_address mock idempotent, by not requiring instance data Fixes fog#2586 A hack to fix the Claim#messages= hack on 1.8.7. Replace the JSON round-trip with #stringify. Missed a chance to use queue.claim!. Include the oldest and newest message in stats. I guess there isn't really a better place. Don't use `&:to_h` style enumerations. Only extend the TTL of a MockMessage. Make the delete_message mock consistent. Yep, just did that. Er, actually enable queues_tests, too. Refactor PATH_BASE into a constant. Enable the queues_tests in mocking mode. Er, *actually* enable the messages_tests for mocks. Enable the queue_tests in mocking mode. Enable the messages_tests in mocking mode. Enable the message_tests in mocking mode. Enable the claims_tests in mocking mode. Enable model tests for Claims. ...
im squash my commits in one |
[OpenStack] Decode body to array
@Bugagazavr Thanks for all the help on this! 👍 |
Thanks for both of your patience and help working through this! |
@geemus I searched though the code base and it appears that there are a couple other places in fog where this is an issue. I am going to try to submit a pr for it later today. |
@krames - good call, hadn't even thought about that. I suppose in some cases it may not matter as much (ie AWS is unlikely to suddenly change capitalization, though it may vary between different openstack providers). |
@geemus I grepped through the fog code base and this problem seems to be particularly prevalent. Rather than update all these references to I created the following excon issue excon/excon#366 for this. |
Thanks! On Fri, Jan 31, 2014 at 1:43 PM, Kyle Rames notifications@github.comwrote:
|
Hi, im use Selectel (http://storage.selectel.ru) cloud with openstack swift (auth api v1.0), when i try to get_container, im got an error:
Because selectel cloud send me
data.body
as string, not arrayThis is a small fix that allows you to convert a string into an array if it is not.