Planet GSLUG

It's day 3 here at FUDCon Berlin. Day 2 was a whirlwind of presentations, talks, conversations, greetings, and collaboration.

I attended Steven's talk about using Koji at CERN which I must say was really awesome. CERN is using their own instance of a koji build system to build rpms that are then deployed across the grid they have around the world. He talked about how much better koji is than their old build system, but also had some questions about how to improve his use of it and their strategy around it. They also need to produce .debs and would like to do so via koji so that should be interesting.

I also went to, and participated in the Git for Hackers talk put on by Yaakov and Jeroen. I even got to get up and show people some of my favorite things to do with git. I learned some new things too which will make my development efforts just that much more easy.

Josh Bressers talked to us a bit about security, and the RHT security team and how they interact with Fedora. He was amazed at how responsive the Fedora project is to security issues, often fixing them before the team he works on is able to check in on Fedora. He is looking for more ways to get involved though. I set him off thinking about what kind of code review we can do in an automated way as code is checked into packages.

Finally I gave two talks (linked to in an earlier blog), one on the future of the Fedora Development Cycle, and one on Automated QA.

We had a rather adventurous dinner in which I got to sit at a table with folks from Romania, Italy, Germany, The Netherlands, and more. It was a fun evening of comparing cultures and food and sports and life styles. The great conversation made up for the fact that food took over an hour to show up (the drinks didn't hurt either).

Today is a hackfest day, and I'm working more on the autotest packages for autoqa. I also got to learn about Fedora FEL which is a fantastic agent of change, not just a simple remix of packages. Chitlesh really has something special going on and I'm glad to see that Fedora was able to provide the platform to launch his efforts. I look forward to seeing more success out of his project. Later he asked me about a problem he was having with his Fedora Hosted site, and I'm looking into updating the git plugin to help out. I also got to meet and talk to Phil Knirsh, mostly about the Fedora on s390 effort. They're ready to start composing images which means I'm going to have to be ready to start writing or reviewing pungi packages as I'm certain there are changes necessary to make it work for s390. I look forward to it, but please, don't send me an s390 (: (I wouldn't mind a beagleboard for playing with Fedora arm...)

I'm going to head out a little early this afternoon and try to see some more sights, like the DDR museum (no not that DDR) and maybe a few other places.

Tomorrow begins my 36~ hour Monday. Boy will that be fun. After I get home and a quick night of doing laundry, I'll be taking a few days off with my wife and son and we'll be staying at my uncle's lake house in Lake Chelan, where I'll be on a boat!

I pitched two barcamp sessions for this FUDCon. The first one is Fedora Development Cycle 3.0, which reviews the recent Fedora Activity Day I ran recently and explains where it is we're trying to go with our proposals. The second is a review of the AutoQA project, where I will explain what the project is, where we're at, where we're going, and where we're looking for help.

I've uploaded the slides to my fedorapeople page. Enjoy!

It's day one of FUDCon Berlin 2009. Max gave a good intro talk, working in just enough subtle Michael Jackson references to set the mood. Hackfests today, as well as pre-arranged talks in our area that were put on the LinuxTag agenda. Hackfests are a little light, I think there are too many people still trying to take part in the pre-arranged talks and the other LinuxTag offerings. However the wireless folks seem to be making loads of progress by all being in the same room. I sat in with the Red Hat Security team and discussed some issues regarding security and package signing in Fedora. It was very helpful to have them all there. Also loads of other people who have taken advantage of face to face time to have high bandwidth quick discussions has also been very valuable. I feel that we've talked about and reached understanding of things that would have taken weeks or longer via email/IRC.

I'm putting some final touches on the talks I wish to pitch at our barcamp kickoff this evening, and then bracing for the FUDPub impact. Tomorrow will be all FUDCon all day and should be interesting to see how many new faces we see here at the event. This being my first non-North America FUDCon I have no idea what to expect.

As mentioned before I have a flickr set for LinuxTag and FUDCon as well as a fudcon tag that others are using as well. I'm also microblogging over at identi.ca for more frequent activity.

Earlier this morning I had an idea to propose an online poll after following a discussion on the freebsd-ports mailing list about what to name the new category for internationalization ports.

Here are the results so far...


Voting goes through Saturday 8am PDT.

I've created a set of photos in my flickr for LinuxTag and FUDCon Berlin 2009. You can follow it here. All the photos should be tagged with fudcon as well.

Upon returning from Open Source Bridge in Portland last week, I collected my thoughts from the convergence of configuration management developers and wrote The Configuration Management Revolution, centered around the idea the something bigger is happening than we’re acknowledging.

Today Tim O’Reilly posted a blog entry about the origins of Velocity. He says “I had been thinking in the abstract about the fact that as we move to a software as a service world, one of the big changes was that applications had people “inside” of them, managing them, tuning them, and helping them respond to constantly changing conditions.” which builds on his post three years ago about operations becoming the “elephant in the room”.

That article is worth revisiting. It tails off commenting on the lack of open source deployment tools. That has definitely changed, as we have a number of open source options in the operations tool space now. O’Reilly has published a few books on operations as well, although hasn’t taken the step of considering it a category in their book list yet.

The web is full of howtos, blog posts and assorted notes on piecing together open source software to build a server. One doesn’t have to be an expert on all of the ingredients, but rather be able to figure out how to assemble them. As time goes on, the problems of the past become easier to solve; former creative solutions become mainstream and the industry leverages those advantages. This frees up mindshare for something new. I’ll emphasize that this doesn’t mean one no longer needs to have some understanding of why the server works, but the time spent engineering that particular solution is reduced because we already have the wheel, so to speak.

Writing configuration management and thus infrastructure howtos may get one started, but it’s the old way of thinking. If you can write infrastructure as code, you can share infrastructure as code. It is essential that this is achieved in a format that both promotes sharing and is relatively easy. Take the Munin and Ganglia plugin sites for instance. Munin is relatively easy to get started with and has a simple enough site for exchanging plugins. While I consider Ganglia technically superior, it’s community is not. I tried submitting to Ganglia’s plugin site once and failed. This step has to be more than a site where files are dumped, it needs community support.

I asked Luke about this at OSBridge and he said Reductive Labs plans to have a module sharing website online soon for puppet. For now, you can find an number of puppet modules in the wiki. Opscode is on track, with their chef cookbooks available as a git repository on github, combined with a ticketing system allowing users to fork, modify and contribute changes. There’s even a wiki page helping to instruct how to leverage these.

Of course, you’ll always need experienced engineers to design and tune your infrastructure. However, the time and mindshare savings from creating a LAMP stack by setting a tag or role to ‘lamp’ is immense. As Opscode produces more open APIs between parts of their product, my mind imagines the offspring of the Chef UI and virt-manager. How long until the popup touting “New features are available for your web cluster”?

The revolution is coming, and it’s about time I wrote about it.

About a year and a half ago I was settling in to a new system administration job at a startup. I was told a consulting company would be coming in to bootstrap configuration management for us. I had previously glanced at cfengine out of curiosity, but ended up spending only a couple of hours looking at it. In my mind configuration management was analogous to unattended software installation, which I was definitely in support of, but had yet to perceive how it was going to change how I viewed infrastructure.

That consulting company was HJK Solutions. Some of my coworkers had previously established relationships with a couple of the partners of HJK, but I didn’t know anything about them myself. I was along for the ride. They gave us a presentation where they showed iClassify and puppet working together to automate infrastructure for other clients, but it wasn’t until the next meeting where we made technical decisions about the implementation that I really came to appreciate their insight. It is much more interesting why someone makes a choice than the choice itself, and this was my first of many since opportunities to incite the opinions of Adam Jacob.

A year of using puppet later, not only was I hooked but my excitement about the possibilities of configuration management had grown beyond what the software could do at the time. Both my excitement and frustration was apparent and got me a sneak peak at Opscode’s Chef. The design of Chef embodies “the unix way” of chaining many tools together insofar that it allows us to take building blocks that are essentially simple on their own but from behind our backs present a system that is revolutionary enough we almost fail to recognize the familiar pieces of it.

Chef is a systems integration framework, built to bring the benefits of configuration management to your entire infrastructure.

This is not an article about Chef, this is about the big picture. However, if you take enough steps back from that statement it becomes apparent that Opscode is building toward that picture. I want to share with you the excitement that short description garners inside of me.

Configuration management alone is the act of programmatically configuring your systems. Often the benefits are conveyed in support of process, but in more agile communities different advantages are touted; such as allowing one to wrangle larger number of servers by reducing build times in the name of vertical scalability, building more maintainable infrastructures by leveraging the self-documenting side-affect of configuration languages, and reducing administrator burnout by cutting a swath in the number of repetitive tasks one must perform. These are unarguably significant boons. Nevertheless, one does not have to look hard to find a curmudgeon reluctant to change, claiming they don’t want to learn another language, that having systems run themselves will surely cause failure, or perhaps some skynet-esque doomsday scenario. History is not short of examples of luddites holding steadfast against new technology, but it is somewhat paradoxical to see this mentality held in such a technologically oriented field.

The recent Configuration Management Panel at the Open Source Bridge conference in Portland amassed many relevant core developers in one city long enough to provide a good vibe for the direction of the available tools and underscore our common charge. But the focus was more about how we will get more users of configuration management tools than why they are going to have to use them. In retrospect, perhaps I should have asked of the panel their views of how configuration management will reshape systems administration.

Configuration management is about more than automation. Some who have foreseen this have started to convey this by discussing managing infrastructures rather than systems. In analogy, the power loom, Gutenberg press, and intermodal shipping container were not merely time saving tools of automation. These inventions reshaped more than their workforce and industry, but also the global economy.

I’m fully aware of the tone set by such a call of prophecy. How will a tool that helps us configure multiple machines at once make such significant ripples in our day to day lives of the future? It will because we will be enabled to solve new problems that we did not yet realize existed. As other technological advances served as a catalyst for globalization, the industrial and scientific revolutions; changing how we build our information infrastructure leaves us poised for an exciting set of challenges that do not yet exist.

Seriously there is Internet in my pants!

Posted via LiveJournal.app.

I'm now a flickr..er? My account is "iamjessekeating".

Posted via LiveJournal.app.

I'm now a flickr..er? My account is "iamjessekeating".

Posted via LiveJournal.app.

After our 2~ year trial with T-Mobile, we're running (not walking) back to AT&T. We are also have new numbers since nobody around here expects a 617 area code.

If you happen to have my old number stored somewhere, contact me (or just call the old number and listen to the voicemail prompt) and I'll give you the new number.

When Fedora first started, there was Fedora Core, done by Red Hat, and Fedora Extras, done by the entire community (including Red Hat people). Core was special, and treated different. Core was defined by "It was in Red Hat Linux". Core packages were.. lets face it, junk quality for the most part. Extras had a set of standards that didn't seem to apply to Core, and if you were lucky enough to work for Red Hat, you could get your package into Core and avoid pain. Core would have releases, Extras just sort of flowed. Core was on the DVD/CDs, Extras weren't. Core had updates with info and a tool to manage them. Extras not so much. This was 1.0.

Around Fedora 7, Core and Extras went away. There was just Fedora. All packages were outside of Red Hat. All packages had to adhere to a set of standards. It didn't matter who you worked for, you could get a package in "Fedora", as well as on the DVD/CD. Fedora had releases, and freezes. All packages use an update tool and have info about the updates. All packages went through freezes. Only one development tree, and was the "release to be", which hid "next release". This is 2.0. We are here.

Fedora Activity Day - Fedora Development Cycle 2009 just happened, as did the release of Fedora 11. We looked at our development process and identified a number of things wrong with it. We picked important items and researched why we felt things were wrong with it, and what we were really trying to accomplish. We prototyped solutions to the issues. We drafted a number of proposals. Where we go from here is up to the community, but this really feels like a major step, and perhaps Fedora Development 3.0.