Another story of persistence and divine inspiration on a small scale making up for my foolishness.
I’m not a hardware guy, so sometimes I take it for granted that hardware will just work. Earlier this year I got a new Samsung Galaxy S4 and pulled my 32 gig SanDisk SD card from my old phone to the new one. Worked great for a long time, bunt a month or two ago it randomly complained that the SD card had been removed. I assumed that it had come loose from the socket and just rebooted. That worked. It happened a few more times and I just restarted each time and it was fine. Then once it came back and the S4 said it was blank. I googlers for an answer and found similar complaints. This time I took the card out and into my Win7 laptop and let it repair the card. That worked.
At this point, I should have taken it as a bad sign and tried another card.
Son the blank thing happened more and more. I was starting to resent the phone. Then one day two weeks ago I couldn’t get it to reconnect even after restarting and reseating the card. It was just reported as blank and the S4 offered to reformat it. I tried it in multiple computers and other devices but the no luck. My laptops built-in slot didn’t even cause a pop-up in Explorer. So I contacted SanDisk and they said they don’t offer recovery services but they would replace the faulty card. They recommended a service, but for 32 GB they charge $275. A few snapshots and save games aren’t with that.
So I tried playing around with it one more time before sending it in for replacement. This time I got out a cheap USB SD card reader, which oddly enough gave a pop-up when inserted, though it still said it was unformatted. I tried the demo version of ZAR, but it claimed the format was unrecognized. Defeated, I thought I’d try the only thing left to do – I put it in the S4 and allowed it to reformat it.
Well, the S4 did its attempt to reformat but then claimed it was blank. So I thought I’d pull it to the laptop again and see of I could let ZAR try to recover files. But this is the miracle – Windows recognised it and opened the folders!!! So I quickly copied all the files off it!
So persistence paid off, and now I can send the card in for a replacement (which will go in my Slate 7 because I’ve put a Kingston card in the S4 now).
Monthly Archives: July 2014
Block heads using Cinder
This is a bit of a case study in the day-to-day work of a software engineer, tied in to a tech tip for OpenStack. I’m going to throw a few footnotes at the end, so if a term doesn’t make sense bear with the story and I’ll explain it at the end. 😉
In my day job, we are building foundational services for provisioning of servers, networks, and other resources. We already have a slick platform for this, but are always improving it. This week as we were working on a recovery story and needed a way to find out if a particular volume had been created, we wanted to query Cinder for some matching metadata. While we knew it was possible, none of us was sure of the syntax. So we went to googling for some documentation. But our searches for “query parameters” to OpenStack Cinder were frustrated. So we tried looking into the source code for Cinder – its open source and Python, so it is all on github and mostly readable. That led to some slightly obfuscated code that led us to believe there are filters that can be used. More googling for “filters” and “search parameters” led to the command line tool for Cinder.
With the proper environment variables in place, the Cinder command line tool works like this:
cinder list –metadata mykey=myvalue1
Getting closer. But we want to use the REST API. So on to experimentation. We knew from the limited docs and source code that the volumes URL was what we wanted.
So to try it out, I wrote a quick bash script to invoke curl with the parameters we needed, including the Keystone token. We quickly determined that the JSON metadata query (which can be a partial match to the metadata stored for the volume) needed to be
URL encoded. Another quick Google and we had an interactive URL encoder up in a browser to run our test JSON string through ten cut and paste into the bash curl script.
But something was still not right. Finally it dawned on me. When I first wrote the curl command, I wrote it like
http://localhost:8776/v2/{tenantid}/volumes
And naturally when I wanted to query I slapped a / on the end then the query parameters, like
http://localhost:8776/v2/{tenantid}/volumes/?metadata=%7B%22blah%22=%22blah%22%7D
Anyone spot where I went wrong? ‘volumes’ is a resource, not a path, so that slash is sending the request off to nowhere.
Take out the slash.
http://localhost:8776/v2/{tenantid}/volumes?metadata=%7B%22blah%22=%22blah%22%7D
Took longer than it should have, and could have been avoided with a few lines of documentation.
While there is a lot of OpenStack documentation out there, the little technical details can be hard to find. And this was a case where just getting the right key words into Google wasn’t enough.
OpenStack Cinder is a block storage service used to allocate chunks of hard drive space as virtual volumes for use by virtual machines or attached as external storage to real bare metal servers.
JSON is a markup language like XML but much terser and easier on the whitespace. I rather like it as long as you have a checker handy to catch missing commas.
Bash is a common shell scripting language. cURL is a command line toll for sending a request to a URL, which is really handy for repeatedly testing a REST API. REST APIs are a pattern for remote calls to a server, and I’ll say that the wikipedia article for REST has many more technical words than I want to type out on my 7 inch tablet. 😉
One more reference if you are looking for Cinder documentation.
developer.openstack.org/api-ref-blockstorage-v2.html