Posts Tagged ‘rant’

I am so very tired of hearing about “the cloud”. Over lunch the other day a co-worker decided we should just call it the phog instead since the phog does a better job of describing exactly what is meant by the cloud.

Why is phog a better description? The phog has no defined shape, you can’t see clearly in it, its different everywhere you go, and once your in the middle of it you can’t find your way out (due to marketing fluf).

You cant have escaped all of the cloud stories in the past year or so. The one that just sent me over the edge was a press release about Vmware buying SpringSource. It is basically Vmwares approach to supplant Xen as the major phog platform. I’m not sure exactly what rubbed me wrong and sent me off into this tirade. Its very possible that I just don’t like Vmware and the first article I read used the more popular term for phog putting me in this tizzy. It’s also possible that I was already on edge about Vmware after my recent discussions with one of their sales people.

For a bit of background Vmwares sales goons are spreading the F.U.D. hard core. One sales goon recently told me “Xen is dead in the water”, “No one is using Xen”, “With all of Citrix’s advertising about Hyper-V  they don’t seem commited to the Xenserver product”. That along with “Everyone is going to KVM”, and some other slams about Xen not having dom0 support in mainline. Of course its fine that I don’t even have the option of running the Vmware hypervisor on the distribution of my choice, and no mention of the fact that dom0 support being mainline really has nothing to do with a Citrix products future. It’s not just a sales guy, I saw a similar slide against Citrix for their work with Hyper-V in a Vmware pdf (See bottom right corner). Anyway, on with the original rant.

As I was saying I was already on edge, and one more phog article shows up. What is the phog? Really? Its hosted applications, no more. Maybe a more programmatic way to define what services you would like and when you would like them available, but its nothing more than paying someone else to host your application servers.

This brings me to another point, and another thing that I wish developers would learn from system administrators (see my comment on Matt Simmons blog for context). Many of my developer friends think its perfectly fine to host everything on someone else’s equipment out in the phog. I feel it is one of my responsibilities to keep data safe. How can you keep data safe when its all out floating around in the phog. I have nothing against scaling out to the phog especially for high volume times but I still think that your core infrastructure should be managed on your own equipment where you can walk up to it and touch it if you want (even if its in someone else’s data-center).

I even had a conversation with a new co-worker recently who thinks everything, your data, downloaded content, desktop etc … will all move to the phog eventually. Ewwwww I can’t fathom letting my data slip that far from my hands.

Do you really think the phog will take off long term? What do you think about most of my developers friends points of view that putting _everything_ in the phog is acceptable or even a good idea?
~

I recently had to write an init script for our continuous integration systems remote build agent. Of course this agent is a java jar and does not write its own pidfile. On debian or gentoo (yes I used to rice it) this would not have been an issue. Both have and use start-stop-daemon in their init scripts. start-stop-daemon actually understands that not every process you might want to daemonize writes its own pidfile and thus gives you the ability to daemonize a process, capture its pid, and write a pidfile.

Oh, but not on redhat/centos. No, they have daemon(), which really doesnt do much of anything. <pompus voice> Each process must write its own pidfile </pompus voice>. Well I already have a custom init script, I really don’t want to write a custom wrapper, nor do I want to add yet another dependency to what ought to be a simple task. Perhaps I just don’t see the proper way to do this so I welcome solutions. This feature lack causes lines like this to show up in init scripts.

PID=$(pgrep -n -f "$LAUNCH_CMD")

I don’t know about you but that is horribly ugly and error prone in my eyes.

chkconfig, the other suck.

Yes its documented that the tags chkconfig and description are required or your init script will not support chkconfig. That’s all fine and dandy. I copied my init template from /usr/share/doc/initscripts-8.45.25/sysvinitfiles. It has doc at the end of the initscript after exit is run. This is perfectly valid. There is nothing that is going to cause issues with the execution of the script. I left that doc there as I was developing my script. When it came time to chkconfig –add my script it continually failed. Granted it only took me a few minutes to figure out but what fixed it? Oh yes by removing all the doc at the end of the file. Why is this conflicting with chkconfig no reason that I can see to make it just not work. It would make a bit more sense if the example tags below just overrode the ones at the top of the file.