It's a mystery
It's funny how things work out despite everyone's best efforts otherwise.
Last June, a division in our company submits a request to upgrade one of their business-critical applications to the latest version. It gets added to the project list and requires quite a bit of coordination since it involves a new server, a new version of Oracle, and new storage.
Our Oracle DBA's indicate it will take about two weeks and schedule it for August. As you might expect, the schedule slips into Septembeer, but really the Oracle DBA's do a good job of not letting it slip any further.
The Oracle DBA tries the upgrade in a test environment and runs into several problems. With the help of the application's support people, he gets them resolved but requests that we push the install date back one week to let him attempt the install again from beginning to end.
The representative from the division goes ballistic. It's been *five months* since she requested this upgrade - why do we keep delaying? I frown when she says this in a meeting and count on my fingers... July, August, September. Seems like three months to me. The user keeps saying "five months" over and over, but I keep my mouth shut - no need to torpedo my career because the user can't add.
The Oracle DBAs sigh and cave in. So we start getting the hardware set up. The server is no problem - we have plenty and to spare. The disk is another issue. For reasons surpassing understanding, we don't control our disk farms - another office in Arizona does. We ask them to honor the scheduled request for disk. The SysAdmin says he'll "try to get to it". Our wailing appears to fall on indifferent ears.
Meanwhile I'm setting up our Linux server to meet corporate standards, which means I don't do a default installation - no need to enable a web server, for instance. When it's done I hand it off to our Oracle DBA, who begins the Oracle install.
Unfortunately, the install fails. Seems we're missing some libraries. The DBA calls Oracle support, then brings the phone over to my desk. Seems that Oracle can see that we don't have the default Linux installation - and shut down the support call right then and there. Because we didn't start with the default installation, Oracle won't help us figure out which libraries we're missing. The woman from Oracle actually says, "It's like you started with a Tudor house and want to turn that into a ranch house. You can't."
It is on the tip of my tongue to tell her about my log cabin built from the bodies of Oracle support engineers, but I refrain. Instead I tell her that I don't want analogies, I want a list of necessary libraries. She refuses to provide them - she said it could be thousands of libraries. She smugly states that she's told this same thing to a hundred guys like me, and they all end up reinstalling the OS to the default installation.
By now my dander is up, but I simply end the support call - arguing with the support engineer isn't going to get me anywhere and we're under quite a bit of time pressure, as there's another mission-critical project waiting in the wings for us to start. Instead, the Oracle DBA sends me the error message he gets during the install. I plug it into the interweb and come back with some pages about a needed library.
I install that library, find that I'm missing a few dependencies, and install those as well. The Oracle DBA attempts another install, and it fails with a different message. Again I search the web, and find that the error messaage indicates we're missing another library. I install it, the DBA attempts the install - and it works. It didn't take thousands of libraries, only about a dozen.
From then on the problems evaporate. The guy in Arizona seems to have actually provided the disk without telling anyone, so we mount it. The rest of the upgrade goes without a hitch and is actually completed ahead of schedule. The user is ecstatic and tells the DBA he's awesome.
Me, I consider this my victory over the Tudors. I used to do technical support, and I know the difference between someone genuinely trying to help you and someone who will throw up whatever obstacles they can in an attempt not to do any work.
So despite an impatient user, a recalcitrant storage admin, and an obtuse Oracle support engineer, the project was completed successfully. How was that possible? I don't know... it's a mystery.
Comment: No doubt
No doubt it will remain a mystery even after the next performance review cycle, when no mention of the success is to be found. Expect some mention of your sabatoge with the non-default installation though.
On the other hand, with luck you won't be blamed for the pushback.
Good work!
Comment: and yet
soon when the vendor says our webapp will only run on the configuration Jump ver. 2.6.6.6.6.6.1, we will ask "how high" in mid-flight.
As we authorize another upgrade schedule from Oracle.
People are Smart!!! -ditech tells us.
hmmmm.
Comment: Translation:
What that support tech's statements really meant: "Non-default Linux installations are not covered in my script, and I don't know spit without my script. Come back when I can follow my script and I'll talk to you."
Comment: A bit like newsreaders just
A bit like newsreaders just mouthing out what's put in front of them. No thought into it etc.. Good post.
Comment: So True
What I really liked about your posting is the fact that you took us through the real live yo-yo of a project. So many times during a project I've hit what appear to be insurmountable problems or support tech. Sometimes I have caved and gone back and started over, but more often my approach is to fight on and 'waste time' looking for work arounds.
The best part of these through the gears and grease victories; you now understand the libraries better then 90% of the support techs.
Just make sure you let your BP return to normal before attacking another windmill.
NIPXIR - mmm a nip of elixir, well it is Friday!
Comment: Now What
You compleated your project despite an impossible deadline, interfering management, poor vendors, and no support.
Now they will expect us to do it too.
Comment: I've encountered this situation before...
boardflak says:"What that support tech's statements really meant: "Non-default Linux installations are not covered in my script, and I don't know spit without my script. Come back when I can follow my script and I'll talk to you."
OMG, I've run into this attitude so many times with "Manufacturer Tech Support" that I can see it coming from a mile away whenever I encounter it. I recently had a Belkin call center flunkie (yes, I know Belkin routers aren't the best, but I these were darned near free) try to tell me that my problems were stemming from the fact that I was running Debian (Testing) on my notebook instead of Windows XP. Nevermind the fact that the router ran perfectly fine for a year with various Linux distros, or that the other Belkin router at home runs perfectly with the same notebook. It was all I could do to refrain from using four-letter words while telling him he was full of [fill in expletive here] and didn't have a clue as to what he was talking about. I eventually ended up solving my own issues and fired off a complaint to Belkin (not that I think it will make a whit of difference, but it felt good).
Comment: With many similar eperiences...
I now resort to Google for the first line of support!
Comment: Now there's an idea.
Next time support gives you trouble, ask them flat out why it is easier to use Google than it is to use their support department.
To the OP: while it would indeed be easier just to list the libraries that are required for the upgrade and get all users to ensure those libraries are loaded, many times a simple patch will come through (not a major upgrade, just a patch) that requires one or two others. The simplest solution is the default installation in the first place, that way all of the usual libraries are already there.




Comment: Well done. Good for you
Well done. Good for you knowing that the support engineer really meant "won't" when they said "can't"