Child Processes

When we, some of my peers, talk about "child processes"...

20 years ago the discussion was around the question of "who all is running netrek, and can we have someone who is root kill their process?". This was a quality of life issue, a very real first world problem.

15 years ago it was about zombies. Software usage was such that we started noticing quality. Child processes that became zombies. Seriously, zombies.

10 years ago  it was all about tuning Apache such that it had the optimal number of "children" such that you would not go into swap because you miscalculated the amount of memory that would be used. We often had too many children.

5 years ago the debate around child processes vs threads became a real conversation due to the changes in hardware. 

Today? 

I find my peers talking about child processes and sleep time, where child processes are in the 1 week to 12 month range with a average sleep time that is anywhere between 2 and 8 hours.

*) Can you find reversed joke in the above statement?

Installing Open Stack

It took me 4 hours to go from bare metal to a small cluster of computers today.

The install was done on Fedora (Redhat), and included Horizon, Nova, Swift, Cinder, Glance, and Keystone. This was using Folsom.

I hit exactly one install bug that I fixed in under 10 minutes. I fed Pepper once. 

Not bad.

Burning Man, Steve Jobs, The Importance of "use" over "testing"

My only real contribution to Burning Man, beyond the price of my ticket this year, was to help Ignite BRC by carrying a monitor to Center Camp, and to point out that Steve Jobs had now left the building.

How did I know that Steve Jobs had left the building?

I did the see the news reports, the book, and had walked past the memorial that someone had built on a local street corner. This wasn't like the moment in grad school where I had to ask "O.J. did what?" when one of my students tuned on a radio in class to hear the jury report. 

But how did I really know that he was dead?

A week before Burning Man my laptop failed to work with a projector. This is how I knew Steve Jobs had departed this world.

I doubt Steve ever touched Mountain Lion.  My presentation was given from a brand new laptop, with a shiny from the factory setup of OSX. 

 

Out of the box my OSX setup did not work with the projector. 

That would have never happened if Steve had been actively using Mountain Lion. 

Can you imagine what would have happened to the developers if Steve would have been alive, let alone experienced, such a simple failure of technology? 

It would not have been pretty.

One week after my own experience with OSX not working with a projector I found myself in a different environment reliving project-fail. 

There is something to be said about knowing for certain that the reason that the laptop sitting in front of you is not able to run a presentation is because the OS is at fault.

I was standing in the desert, in a giant circus tent, with dust in the air, staring at a hodgepodge of cables that were connected to some ancient CRT. There is a lot of things that might be contributing to the problem.  

When I was asked, "why isn't this working?"

The most useful thing I could contribute was:

"Running the presentations off a mac isn't going to work; the laptop is running Mountain Lion. Go find a Windows laptop."

The presentation was moved off the Mac, and onto a PC. 

The PC immediately worked. 

I am wondering if anyone at Apple used Mountain Lion to give a presentation before it was released. It is hard to imagine that someone didn't run into this problem long before Mountain Lion was released (as far as I know Apple has not  fix the bug yet).

I am sure that there is a lot of testing happening each release.

Testing software is not the same as "using" software.

Apple is a company, someone, at least once a day, must be giving a presentation. 

How did they miss this?

Steve Jobs would have presented Mountain Lion to the world using Mountain Lion. 

If that presentation had blown up on him,...

Egads.

Drizzle 7.2.3

From the release notes:

Fix for CTRL-Z for shutdowns. Many updates for JSON server. Improvements completed on Catalog support. ZeroMQ and Gearman supported updated. Updates AUTH_HTTP authentication module. Documentation enhancements. Testing framework updated. Regex Policy updates.

Stewart can say a lot more about Catalog support, but this is one of the cooler bits of work that is happening ongoing. The original work was began for Rackspace and continues today. Virtualization inside of the database is long overdue.

The JSON server is another one of the locations where we see a lot of effort. Being able to support JSON queries directly seems to resonate with a lot of folks today.

For the record I wrote zero lines of codes in this release. Work continues, and in the case of Drizzle it is all about work coming in from the community :)

Drizzle 7.1 Released

Drizzle 7.1 was released!

The laundry list for features and improvements are pretty long, so I will leave that to the main blog announcement.

The part that I find the most interesting? 7.1 was the effort of a lot of developers and people who do the heavy lifting of promoting the project (and the efforts around a project like this are huge). It takes the resources of a half a dozen companies directly, and a number of companies indirectly.

Compared to 7.0, Drizzle was done by volunteers, not paid Drizzle employees, who find the project fun and interesting. These are people who want to be involved with the Open Source Community, and who find value in the work (and looking at our incoming Google Summer of Code applicants there are more people to come).

The biggest surprise that some might fine? Much of the 7.1 effort was done by new developers. These are people who never worked at MySQL, Sun, or Oracle.

Contributions by new individuals make up the bulk of the 7.1 effort, and I am very happy to see that. It it is evidence of the ongoing growth of the Drizzle community.

One Fat Bird

Opscode's Chef, MySQL, Best Practices

If Chef manages a CNF file, please have it put a comment in the top of the file that it is managed by Chef. Do not assume that everyone will believe that every file is being managed by Chef. In general, you should have Chef leave a comment in every file that it manages (and someone at Opscode should make this a default feature in Chef).

Do not have Chef reboot the database. Databases are designed to run for years at a time. Many parameters can be set while the databases is running in such a way that it does not need to be bounced in order to make the parameter work. There are exceptions to this in non-production environments.

Need to change the schema? Do not have the Chef create a table, and then do alter table after alter table to install a new system. This is very painful to watch.

* Thanks to Alex Howells for the idea of always putting a comment in the top of the Chef script.