Wow, it has been a LONG time … but I’m back for a short episode. I’m focusing mostly on misunderstandings about why Apple does what they do and how they go about doing them.
In regards to web technologies, or what people think are web technologies.
Podcast: Play in new window | Download (Duration: 8:42 — 6.0MB)
Subscribe: Apple Podcasts | RSS
I’m not going to rail against 3rd party vendors here, but I do want to point out one area where I have found an extreme weakness … the same one pertaining to two different vendors.
We are looking at a domain name switch here on campus and luckily, we have the domain name. Sadly, we can’t add it to your Google Apps for Education account (yet) because it was used prior by someone else. That stinks.
So I’ve been working with support for the past week trying to get it added to our account, but no luck so far. I’m supposed to have more instructions later today, but they said that yesterday as well. All told, I can’t add the domain to our account which means I can’t really start the move tot he domain.
I have run into similar issues trying to add my email address to my personal Google account because I had used that domain in Google Apps in the past. Support has not been able to help me with that one so far.
Then, I want to try out Microsoft Live for Domains again because I kind of like the new web Outlook. Out of luck for the same reason I can’t add the new domain to Google … it has been used with some Microsoft property somewhere in the past. So I sit and wait for support to get back to me there as well.
If I was running my own server, just having ownership of the domain name is enough to get me going. I don’t need to contend with a vendor’s policies as well, and that is a real weakness. It is hard enough to navigate your own policies but then you need to be willing and able to navigate the policies of another party when trying to get things up and running.
The questions, as always, center around whether it is worth it and what the loss of flexibility and control mean for your institution.
I’m sure I’ll get things worked out, but I would be testing already if I would have kept stuff in-house. I’m not going to even think about whether that trade-off is ultimately worth it right now, but it is something to always keep in mind when faced with the decision of outsourcing parts of your IT infrastructure.
This is my story on how I was able to upgrade our two virtualization stacks to XenServer 6.2. It is a tale of woe, so be prepared.
Where to begin …
We have two virtualization “stacks” consisting of four servers each. Two servers are for storage (Ubuntu 12.04 boxes using DRBD for replication) and two are XenServer hosts. At first we were hoping to use software RAID on the host boxes, but that did not work out.
So, we went ahead and purchased Adaptec RAID 6405 cards for the host boxes even though they were not on the HCL list for XenServer because we thought it would be easy enough to go ahead and create driver disks. While it is possible, it is still a pain.
Worse than that, when we attempted the upgrade to XenServer 6.2 from our 6.1 pools … the installation media would not see the prior installation even when using proper driver disks. We could do new installations, but we could not upgrade pools.
What!?
So … a new plan was hatched. Here are the steps:
Do that for each stack. It allows me to move each host box onto a RAID card supported by XenServer and then allows me to upgrade the entire pool to XenServer 6.2 using the mechanisms with XenCenter.
YAY!
I’ve learned a lot, again, through this entire process … maybe most importantly how vital it is to have a plan ready to go in your head before you start and to follow it as closely as possible. Luckily, this one worked.
I’ll have to wait and see if I am as lucky in the future.
This kind of goes with my prior post, The Importance of HCLs.
As a technologist I have some very long-held beliefs and preferences as far as technology goes. I know what I like to use, why I like to use it, and could talk for hours about why someone else should use a certain technology or consider trying it out (at the very least).
However, when does that fight become counter-productive? When does trying to fit my preferences and wants, my assumptions, start to fight against me and create more harm than good?
There is certainly something to be said about loving the tools that yo use, but what if those tools, for the current job, just don’t work not because they are incapable … but because of factors outside of your control.
Say that you want to use a vendor’s virtual appliances in order to add some much-needed new technology to make things better … but that vendor doesn’t support your virtualization platform. What do you do? Do you spend the time and effort either:
Even if #2 might create a little less work for you in the short-term, think about what that time might mean for your vendor. More resources devoted to supporting more platforms can mean a slower-moving vendor. Apple is the prime example of this … if you want to use Apple’s stuff, USE APPLE’S STUFF. Everywhere. As much as possible.
It is a good fight to get all technologies to inter-operate together, but there are so many things to do, so many improvements to make in all facets of IT that maybe, just maybe, fighting the good fight in this instance might not be worth it not just for you … but for everyone else too.
I was watching a talk recently by Bob Mahar and this quote jumped out at me:
If you do something poorly. It’s easily supplanted by anything.
I take this as a warning against complacency in technology. Many times it is comfortable to let systems continue to run until they start causing problems. An issue arises when things have gotten to the point that they can be replaced by anything just because “it is better”. When you get to that point, ANYTHING is better, even solutions which are overall worse in the long run.
That is one reason to keep pushing forward with new technologies and updates. You want to be able to make the best decisions possible, but replacing technology that doesn’t work can sometimes lead to sub par solutions.