Kolab Now: Another Round of Updates

This weekend has seen a variety of systems being issued either of, or combination of, the following commands;

• yum -y update
• yum –enablerepo=kolab-16-updates-testing -y update
• puppet agent -t –no-noop
• reboot
• rm -f /dev/null; mknod -m 666 /dev/null c 1 3

I don’t expect everyone to know and understand what these pieces mean, so I’ll divide this blog post in to two parts — one for users of Kolab in general, and one for my fellow sysadmins.

A heads-up for Kolab users though — I’m much more verbose in the sysadmin parts of my messaging, and so you just might want to read through even though things go way over your head and land nowhere meaningful.

User-ish Part

Users of Outlook, Thunderbird or Mac OS X clients may see some improvements — if you have been the ones hitting some ActiveSync or CalDAV issues to being with.

For web client users, improved server-side spell checkers could help you avoid some of those common typos and other such mistakes 😉

While I admit very few of you users might have felt the tiniest little bit of pains, I’ve tested the redispatch configuration on our HAProxy, and it seems just perfectly fine to me (aside from a ~3 second delay). Your slight delay isn’t the point; the other tens of thousands of users didn’t experience anything. I would call that a success.

None of our users have seen this pace of change happen to Kolab Now in the past. It is in part because of my efforts to transition to a type of infrastructure that allows it to happen — I deliberately hid it under an upgrade to Kolab 16, which itself was hidden under a datacenter network provider’s service window, but here’s so you know that wasn’t the sole milestone.

We sure have further issues to deal with, but feel assured we can now also deal with them. No Free Software is without bugs, after all.

Sysadmin-ish Part

I first need to state our software delivery is staged — development (your proverbial rawhide), updates-testing, updates. This will clarify some of the following;

Out of the some 250 more traditional type of systems that make up the Kolab Now service, all of them managed through Puppet, our staged deployment includes an ability to promote from development, through testing, to production. See above for a further clarification as to how software releases may apply to systems staged. We can all see how it is more effort to deploy VMs in such environments, to then maintain those VMs, than it is issue a roll-over of containers.

But that’s not what we have. It’s supremely difficult to change over, even though I would count it among my core competencies to head up any transition. Provided enterprise-level hardware has been purchased to provide us with the necessary SDN capabilities, deploying something like containers rather than VMs (at a level of ease and predictability that not even OpenStack currently facilitates) is … intriguing.

We have recently transitioned (almost completely) to an infrastructure with nothing but single-role, single-purpose systems — much more suitable for the transition to a container-like space.

Operating under constraints, I have also almost cleared out two of our smaller hardware KVM hypervisors, so that they may become available for “play”. They may run a Red Hat Atomic deployment, if it weren’t for the fact that those kinds of images are just far too restrictive, and so far my attempts to compose a reasonable image have not succeeded, because WTF-ostree — I’ll likely have to run Red Hat Enterprise Linux vanilla, and then build something that closely resembles Atomic on top of it, but for now; more on the specific efforts to kill arbitrary shit getting in my way later (as you might remember, I too used to be in the business of composing something specific and custom).

This would, more importantly, complete our transition to start doing away with crappy Puppet in favour of awesome Ansible. If you wanted to know anything about how crappy Puppet is, start here, and then while you read it, please admit to yourself that the documentation you’re reading is already long outdated — and yes, I’m supposed to maintain it. My point is that I don’t see the point in updating the documentation on this here Puppet module, because it’s doomed.