Everything is a Freaking DNS problem

This post is long overdue, as the idea struck me when dicussing with Lefred while preparing his Fosdem talk on Maintaining too big tables

I got triggered finishing this post by Mr BuidlDoctor

Fred has been struggling with a typical DevOps problem resulting in the most unmanageable database setup possible, there's little room for him to move but he managed is way out .. because he is good at his job

It set the mark for me that because in different organisations even the Opsteam is fragmented `in different groups that there also we need to get the Devops idea going.

Typical setups here are the Network guys vs the Platform guys , specially with the growth of virtualization where the network stack doesn't stop at the physcial switchport anymore but the vlan trunks go deep in to the VM's a lot of discussion happens. There where traditionally the story for the network engineer stopped at the switch they now want control much deeper in the infrastructure.

But an even bigger group that needs integration are the security folks, it's no secret that in some organisations the security guys job is to be the bad guy, their default reply to something is NO. Specially to people wanting to drill holes in their architecture .

Patrick wonders if its the specialist vs generalist dillemma, I think it's the Web vs Enterprise IT way of thinking ..
DevOps first gained ground in Web environments , the battle has only started ..

We still have a long way to go before in say a banking environment the Devs and SecOffs' and the DBA's and the Ops are on the same line ... they all need to break the walls of confusion, they all need to come out of their silos. And when you are a generalist in charge of a bunch of these things you have to make sure your tuesday afernoon security persona talks with his other persona's from time to time ... otherwise you are really gonna need those meds :)

A couple of weeks a go Brian Profitt pinged me for a chat about Devops , the result of that chat , his article can now be found on the Zenoss blog, it's titled Datacenter Barometer: Better days arrive when dev meets ops

It's a very nice read with some pointers to places regular readers of my blog should already know ;)
So with lots of leading Open Source infrastructure companies on different levels, such as config management (OpsCode and Reductive Labs) , monitoring (Zenoss) , deployment (openQRM, RPath, and obviously Consultancy companies , the upcoming Devops conferences around the planet promise to be a lot of fun ! ;)

Oh, and apparently there is some more on the story on /.

Devops, Devops, Devops, everybody talks about it but we're still defining it ...

There's so many different interpretations possible for the term Devops , It's automated infrastructure, it's agile infrastucture, it's getting devs and ops closer to eachother, it's briding the gap between devs and ops , it's agile system administration, it's the movement , it's the mindset , it's the spirit.

Lots of people, lots of opinions .. Indeed some people have been doing this kind of work for ages, some claim the cloud is what makes devops become visible (but we've been doing cloud since before the cloud marketeers called it cloud)

Some define the devop as a European based , open source backgrounded , thirtysomething senior sysadmin , or should I say infrastructure architect , originated concept . Others claim it's developers gone sysadmin gone partly developer again ..

But it seems like lots of people claim that Devops is more about the team, not about the unique individual doing a job.

You'll have to agree however that our jobs are significantly different from the system adminstration type jobs you'll find at the average IT department. With that in mind: How shall we call this breed of people cooking up chef stuff, playing the puppeteer or cranking up the CFEngines ?

And no I don't like Devministrator :)

No really .. it seems like everyone wants to jump on the bandwagon ...Or just let us know they were already on the pulling the train ..

Brian Moon weighs in that it isn't anything new. Hey .. it's not like we've been claiming that Devops is new ..

The dev2ops guys give their views on stuff ..

The rPath crowd weighs in

And if that wasn't enough ... you really should have a listen to what Jono Bacon and his pall have to say about it

Oh and there's more stuff on the way .. given people being interviewed etc ..

So John wrote down his experiences on deploying Drupal sites with Puppet .

It's not a secret that I've been thinking about similar stuff and how I could get to the best possible setup.

John starts of with using Puppet to download Drush... while I want to use rpm for that ...

I want my core infrastructure to be fully packaged... not downloaded and untarred. I want to be able to reproduce my platform in a couple of months , with the exact same versions I`m using now .. not with the version that happens to be on ftp.drupal.org at that point in time, or with ftp.drupal.org being down.

Now the next question off course is what's the core infrastructure.
Where does the infrastructure end and does the application start. There's little discussion about having a puppet created vhost , an apache conf.d file, a matching .htaccess file if wanted , and the appropriate settings.php for a multisite drupal config.

There's also little doubt to me on using drush to run the updates, manage the drupal site etc . Reading John's article made me think some further about what and when I want things packaged.

John's post lead to a discussion on #infra-talk on getting all drupal modules packaged for Centos with Karan and some others

In a development environment I probably want to have periodic drush updates getting the latest modules from the interwebs and potentially breaking my devs code. But making sure that when you put a site in production it will be on a fairly up to date platform, and not on the platform you started developing on 24 months ago.

In a production environment however you only want tested updates of your modules as indeed they will break code.

It's probably going to be a mix and match setup having a local rpm/deb repo with packaged modules that have been tested and validated in your setup and using drush to enable or configure them for that production setup.

But also having a CI environment wher Drush will get the new modules from the interwebs when needed. and package them for you.

To me that sounds beter than getting all the available Drupal modules and packaging them, even automated, and preparing a repository of those modules of which only a small percentage will actually be used by people.

But I need to think about it some more :)

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

Over 1.5 decade ago, a bunch of us were addicted to irc, I lived on channels such as #coders, #nlcoders, #demoscene, sneaked in on #vlaanderen to see when the Leuven locals were heading to the pub, then started joining multiple Linux and Open Source related channels around 94...

Then some weirdos had an alternative way of chatting ICQ, then the folks from Redmond reinvented the wheel... Luckily XMPP arrived and Jabber became the open alternative, but still all of this time irc stayed

Then twitter came and us Open Source peeps are obviously denting via identi.ca But while Twitter / Identica are nothing more than todays version of Instant Messaging only in broadcast rather than multicast mode irc still stays the best way to discuss.

And irc starts to become more and more active again There are lot of regular project channels and now there is #devopsdays , ##infra-talk and different other channels that are being much more frequented than before again ...

You might wanna join us again on irc.freenode.net that is :)

PS. And whatever they tell you .... Wave is not usable for online meetings ;)

And don't even get me started about Buzz

I would like to point the crowd to the Call For Presentaions of Loadays. , the Linux Open Administration Days .

The Linux Open Administration days 2010 will be the first edition of a new conference focusing on Linux and Open Administration, we are trying to fill a gap for System Engineers and Administrators using Open Source technologies"

More details on the Linux Open Administration Days site

I'll probably be there .. given the fact that the event will be 5 minutes from where I live .

Fosdem 2010 was my 10th fosdem Edition (including the first OSDEM)
As every year Fosdem suffered even more from it's own success.

On Friday evening ther was the obligatory Beer event... however as people need to eat to .. the Devops crowd fled the scene

I had made reservations for a 20 something group and with the CentOS crowd joining us (as there was some overlap anyhow) we were 25 when we arrived in the restaurant .

Dinner and Discussions were great .. I learned about some new projects and we had some insightfull dicussions on how fat your thin foil should be ...

After dinner we went back to the Beer Event were lots of Free Beer was tasted ...

Saturday was the first full day of Fosdem, as usual Fosdem was the victim of it's own success , too much interresting stuff to see .. too little time.

Lots of Devrooms had the "FULL" sign put up more than you want as a visitor ...
I never even made it into the Drupal or NoSQL rooms :(

Sadly I had to correct Ploum's first law but for a lot of people .. Fosdem each time means the battle choosing which presentation you'll go to ... If you can even make it to the talk .. as usually the the hallway track is much more interresting :)

The MySQL devroom was on sunday but on saturday the crowd met in an Italian place nearby the Fosdem campus to get to know each other and chat a lot ..
The discussions ranged from French vs Canadaian and the future of Forks

During Saturday afternoon @patrickdebois suggested a Devops Meetup for Breakfast ... and some how that also happened ...

When I arrived at Fosdem on sunday morning they were still there :)

I spent the biggest part of Sunday in and around the MySQL devroom listening to a bunch of interresting talks

My own talk went fairly well given the time constraint .. sqeezing content for an hour in 20 minutes means you can't really go deep into the topics ...
My initial plan was to only focus on Pacemaker integration however the community had voted for the overview talk :)

After my own talk it was almost time to head to the Janson auditorium for the Footnote of Greg Kroah-Hartman, and as on any Fosdem .. there once again had to be Beer