ah. I thought you were a customer complaining about my bad customer service. We have a ongoing problem of dropping tickets on the floor that we're working on. Part of my problem is that /within my financial constraints/ I will choose someone who is skilled who is not particularly customer focused over someone who is unskilled but customer focused. the other part of the problem is that until recently, I haven't really been 'backstopping' the customer support queue. The problem is getting better, I think, as I have been putting more effort into it, but it's not solved yet.
Of course, unless something breaks on my end (or, more often, the customer loses his auth. key) my customers can reboot their own server, no matter how badly the mess it up. For my system to scale, this is absolutely essential.
Tell your SysAdmins to setup powerman. it's a wonderful tool that lets you control access to different brands of remote rebooters in a very sane way. They could easily set it up so devs can reboot, say, dev, test, and staging but not prod.
I think a /whole lot/ of this current 'cloud' craze is just an overreaction to the bureaucratic problems with internal IT departments... like SysAdmins not providing timely support /and/ not allowing access/tools so that devs can do it themselves.
I think a /whole lot/ of this current 'cloud' craze is just an overreaction to the
bureaucratic problems with internal IT departments... like SysAdmins not
providing timely support /and/ not allowing access/tools so that devs can do it
themselves.
That's definitely one of my reasons for going that direction. As a soon-to-be-an-academic grad student, it's nice to have my own thing I can take place-to-place anyway, but due to inertia, it being free, and essentially infinite bandwidth, I'd probably be using university IT stuff if they would let me do anything on it. But, the fact that I have to round-trip through a person to get anything installed, and also have a big hassle of explaining why I need it and hoops to jump with their security policy, just makes it easier to buy a server somewhere not on the university network where I have root.
I've never seen a university network that prohibited CS grad students from having machines with root.
I've heard of networks like this—in some places I didn't expect—but it is neither acceptable for a research environment nor the status quo and you should push for changes in your department if this type of harebrained thing is preventing your ability to do science.
Oh, I do have root on my own desktop machine. It's getting root on a machine that I can use to serve things up to the internet that's a hassle. The official way to deploy web-app type stuff is to ask university IT to look it over and deploy it on their servers, which they understandably don't much like doing when the webapp includes callouts to a bunch of possibly-buggy research code, some of it from third parties, or depends on stuff they don't have installed on their servers (Prolog, Lisp, etc.). But they also don't like un-firewalling my machine so I can just serve it up from there. Research groups can indeed set up servers that they request to be un-firewalled (a prof. usually has to initiate that), but it's just less of a hassle for me to move web-demo stuff to a VPS.
How come you couldn't reboot it yourself?
Also note, we're pretty liberal with refunds if you decide we aren't good enough.