If I wanted something like this I'd probably just reach for pampy and use pattern matching. Which still isn't "Monadic".
83 karma · joined April 1, 2010
If I wanted something like this I'd probably just reach for pampy and use pattern matching. Which still isn't "Monadic".
I have considered just writing a quicky daemon that will do just the work of syncing routes without getting a lease (or trying to modify flanneld to do so).
The service in this case is memcache with a bunch of mcrouter pods in front of it to handle failure and cold cache warming. I still need to get traffic to the mcrouter instances and that's where I'm running into the bottleneck.
How do you handle gatewaying traffic into Kubernetes from non-K8s services? I've been trying to get a basic cluster out the door with one of our most stateless services, but I'm having a having a hard time just getting the traffic into it.
The mechanism I'm using is having a dedicated K8s nodes that don't run pods hold onto a floating IP to act as gateway routers into k8s. They run kube-proxy and flannel so they can get to the rest of things, but ksoftirqd processes are maxing CPU cores on relatively recent CPUs trying to handle about 2Gbps of traffic (2Mpps) which is a bit below the traffic level the non-k8s version of the service is handling. netfilter runs in softirq context, so I figure that's where the problem is.
Are you using Calico+BGP to get routes out to the other hosts? What about kube-proxy?
He edited their Python script to make a copy.
The only advantage an actual app could have is responding to my hardware play/pause/next buttons, I think.
Under "For Sellers", it says that you get the funds unless they specifically block it.
WTF?
(Incidentally, perlcritic will warn you if you have a map that modifies $_.)
I mean, as it is, I see segfaults and whatnot regularly in the canonical, distro-released versions of Apache. Major software releases all the time with bugs that could potentially be a show-stopper. My experience hasn't shown this to be any worse with non-canonical sources. Sometimes it's better.
Further, I like to think of the sysadmin's job as fostering business continuity. While uptime is a primary indicator of this, I think it's lower in priority than say, losing a crapload of customer data. If I have to shut a site down for an hour to prevent losing all transactions for the previous 24 hours or something, then it's not a terribly difficult choice. (Having to make this choice at all, of course, means you should be engineering something better. But we don't have the luxury of infinite time.)
And having all the uptime in the world won't help you if your engineers can't do their jobs effectively because the tools you give them are insufficient. Sometimes the best option is to suck it up and try that patch.
It's a delicate balancing act, and I'm not by any means advocating running all your software out of unofficial repos. Sometimes you gotta make that call, though. And if I'm looking at github at all, it's probably because a package doesn't already exist, or because I need a fix for one specific bug.
I also know plenty of other sysadmins who use github but find no value at all in Launchpad.
Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom.
Edited to add: I also think that if it's not immediately apparent which fork is the "canonical" one, it probably doesn't matter. Just grab whatever looks most popular. If you decide you'd rather have a different one, then grab that later. shrug
I don't think the "leave it to the users" option really works here. A lot of people will choose the least-work path.
This is still miles better than having all of the customers behind large scale NAT, where you risk blocking innocent folks who happen to be behind the same NAT.
... that description is full of shit. I'll have to talk to my manager about that.
Basically, we need three things from a sysadmin candidate:
We're a Debian/Ubuntu shop, with huge deployments of MySQL. Some of the job is day-to-day management of servers. You should know how to manage databases and handle replication.
We also require solid networking knowledge. You should know about the difference between TCP and UDP, and be able to explain Spanning Tree or ARP. (It actually shocks me how many sysadmins don't have this knowledge.)
The third part is programming ability. Most of what ops does is in Perl, but we also have to interact with other systems, so any knowledge of Python, PHP, etc. will enhance your appeal.
We're doing pretty awesome things, and only getting bigger and better. Come work with me! :-)
(E-Mail to treed@imvu.com if you have any questions or whatever.)