I recently picked up a cheap Acer Chromebook 11inch - CB3-131. It runs Chome OS. While it’s nice as a machine that just works for small things and travel. I found the environment to be a bit restrictive (less fun) to play with. I did try crouton, but it wasn’t what I had hoped for. I proceeded to investigate installing a full linux distro onto my Chromebook and discovered that on some (the one that I got) has a physical write protect screw on the mainboard.
I’ve recently went and updated a bunch of things that I’m working with, and one of the things I decided to refresh was an automated installer. In the past I’ve relied on either hand rolled configurations or more recently Ubuntu MAAS. This time I decided to give Cobbler a try on my Ubuntu Precise installations. Given Cobbler is pretty (or was) RHEL specific, I was not too disappointed with the Debian packaging.
Having recently changed jobs (after a very long stint at TCD - just short of 10yrs!) I’ve moved to a small startup. I’ve been working on a few small bits and pieces of code, infrastructure, etc… I had to make some stuff work and make it work well. So I decided to use autotools to configure and build the application that I’m working on. As great as it was on my nice fast intel based machine, it was dog slow on my target platform, especially when I had to regenerate the autoconf scripts.
I’ve been happily hacking at some packages for hashdist, it’s pretty nice, there other build systems out there for dealing with building applications and libraries with different combinations of compilers and numerical libraries. Out of the lot I think hashdist has been the most satisfying to use so far. It’s still missing some bits and pieces to allow users to use different compilers for key components (or everything). Without explaining too much, it’s basically taking inputs which define a package and then generating an output hash to store the output of the build.
We recently had Hydra Camp in Dublin in Trinity College Dublin which went pretty well. I even got to talk a little about what we’re doing with Shibboleth and how we’re deploying our systems. We’re deploy with ansible either by someone running the playbook by hand or via buildbot which pushes out a build when tests pass successfully on the master branch. Someone in the camp asked at what complexity should you begin to automate at, which I thought was a strange question since at DRI/TCD we thought of deploying as automatically as possible from day 1.
It’s that time of the year again and it seems we’re going to hold another Hydra related event in work at Trinity College, Dublin. For more information see https://wiki.duraspace.org/display/hydra/Hydra+Europe+2014
After going to SC13 and being at a few BoF’s and hearing some people talk about their operations and potentially using Salt to replace the likes of puppet and chef, I decided to learn a little more about Salt. In particular since I have an old laptop lying around at home, I decided to setup a little private cloud. I followed this blog post. It mostly worked apart from some buggy behaviour in the seeding process.
I was recently at SC13 and attended a number of Python HPC tutorials, Data Management and HPC systems engineering and administration BOF’s. This year’s SC13 much calmer than previous years, but I did pick up a few new tools during the conference. However I was pretty surprised that there is a real lack of devops, sysadmins etc… in the this space. I was also surprised at how things like salt and ansible are being adopted in this space.
It’s probably no secret that we use Ansible at our work place for the project that I am working on. So far we’ve used it to deploy and maintain state for our Open Nebula deployment, Jenkins CI system, Ceph’s radosgw and our digital repository. In fact I currently have a Jenkins job which deploys our software stack using Ansible to a test system in our Open Nebula cluster. This has been hugely beneficial to myself so far to be able to teardown and bring up systems quickly to make sure our application is well tested and debugged.
The team that I am working with right are very much agile and we’re doing quite a bit of outside in development of the repository that we’re building. We’re mostly adopting a behaviour driven development with a touch of test driven development. As a result we’re very much in favour of testing things out as much as we can and using the same environments to develop against. As previously mentioned before I had originally been using puppet and vagrant to build up the development harness and experiment with tools/services that we might want to use for our system.