Back in 2006 I wrote a blog post about linux troubleshoooting. Bert Van Vreckem pointed out that it might be time for an update ..
There’s not that much that has changed .. however :)
Everything is a DNS Problem
Everything is a Fscking DNS Problem
No really, Everything is a Fscking DNS Problem
If it’s not a fucking DNS Problem ..
It’s a Full Filesystem Problem
If your filesystem isn’t full
It is a SELinux problem
If you have SELinux disabled
It might be an ntp problem
If it’s not an ntp problem
It’s an arp problem
If it’s not an arp problem…
It is a Java Garbage Collection problem
If you ain’t running Java
It’s a natting problem
If you are already on IPv6
It’s a Spanning Tree problem
If it’s not a spanning Tree problem…
It’s a USB problem
If it’s not a USB Problem
It’s a sharing IRQ Problem
If it’s not a sharing IRQ Problem
But most often .. its a Freaking Dns Problem !
We’re increasingly using Docker to build packages, a fresh chroot in which we prepare a number of packages, builds typically for ruby (rvm) , or python (virtualenv) or node stuf where the language ecosystem fails on us … and fpm the whole tree as a working artifact.
Now part of that build is running the actual build script in docker with a local volume mounted inside the container This is your typical -v=/home/src/dashing-docker/package-scripts:/scripts param.
A child balloon
you inflate it, play with it for a while, then it explodes, you throw it away you inflate another one, maybe even a different color. the kid plays with it .. till it breaks, then you throw it away…
An inflatable castle.
you inflate it, play with it for a while, deflate it, move it around, inflate it again, if it has a hole in it, you patch the hole.
When people sign up for Configuration Management Camp, we ask them what community room they are mostly interested in.
We ask this question because we have rooms in different sizes and we don’t want to put communities with 20 people showing interest in a 120 seat room and we don’t want to put a community with 200 people in a 60 seat room.
But it also gives us to opportunity to build some very interesting graph over the potential evolution of the communities.
I gave a couple of new and updated talks the last couple of months.
At Fosdem, I opened up the Distributions Devroom with a talk on how we could improve the collaboration between the developers of a distro, and their users, the ops folks. I seemed to not be the only person with similar ideas as the smart folks over at the CentOS project were already actively talking about their efforts into making some my ideas become reality the day before at the CentOS Dojo.
There’s been a lot of discussion about the sillynes of the term BiModal IT, aka the next big thing for IT-organisations that don’t dare to change, but still want to sound cool.
So here is my idea to reuse that term for something relevant.
BiModal IT, is the idea where you take a fully automated infrastructure which has been build on the principles of Infrastructure as Code. Which gets periodic idempodent updates (e.g every 15 or 30 minutes, or when you orchestrate it), and consistency checks , where the source code for that infrastructure is versioned , tested and delivered trough a traditional Continuous Delivery pipeline for the majority of your services. and add realtime reconfiguration capacities based on service discovery for the other services that really change fast, or in a real elastic way, using tools like Consul, Consul_template, etcd etc..
Software delivery is hard, plenty of people all over this planet are struggling with delivering software in their own controlled environment. They have invented great patterns that will build an artifact, then do some magic and the application is up and running.
When talking about continuous delivery, people invariably discus their delivery pipeline and the different components that need to be in that pipeline.
Often, the focus on getting the application deployed or upgraded from that pipeline is so strong that teams
forget how to deploy their environment from scratch.
A couple of months ago we were seeing weird behaviour with consul not knowing all it’s members at a customer where we had deployed Consul for service registration as a POC
The first couple of weeks we hadn’t noticed any difficulties but after a while we had the impression that the number of nodes in the cluster wasn’t stable.
Obviously the first thought is that such a new tool probably isn’t stable enough so it’s expected behaviour , but rest asured that was not the case.
Steve Ropa blogged about What done looks like in devops , I must say I respecfullly , but fully disagree with Steve here.
For those of you that remember I gave an Ignite about my views on the use of the Definition of Done back ad #deovpsdays 2013 in Amsterdam.
In the early days we talked about the #devops movement partly being a reaction against the late friday night deployments where the ops people got a tarball with some minimalistic notes and were supposed to put stuff in production. The work of the development team was Done, but the operations team work just started.
