I enjoyed FOSDEM 2012 in Brussels. It was my first time attending, and I was very impressed with the organization for such a large event. There were even sight-seeing trips organized for travel partners not interested in FOSDEM itself. I was a bit surprised actually at the high number of luminaries from the open source community that were present.

My talk on pacemaker cloud went OK. It's the largest audience I ever presented to, with I guess about 450 people in attendance. It's a learning experience of course, so hopefully the next time I'll not waste any percentage of brain cycles flaffing about with microphones and other such nonsense.

The talk was only 20 mins so I didn't really get time to explain the demo in detail, but hopefully people will be tempted to try. A few came up after and said they would definitely try it out. There were about 10 minutes of Q&A at the end which we had to cut short, which was a good sign.

Example questions

Q. Could pacemaker-cloud be shipped as part of openstack?
A. Possibly, but we've not considered that. Openstack is split into separate components like pacemaker-cloud is separate to existing cloud platforms. But we've concentrated on making it work well with Openstack and other cloud providers for now.

Q. Does it generate reports?
A. No, that is seen as a separate task best dealt with elsewhere. We'll just send out notifications of various events.

Q. What if pacemaker-cloud fails?
A. Well there are 2 aspects to that.
1. What's to stop pacemaker-cloud itself going postal and nuking your cloud? Well we've to make it as reliable as possible (increase its MTBF), by reusing known good components like the pacemaker rules engine, and keeping it small and cohesive by not incorporating things like notification archival etc.
2. We could apply the same techniques to pacemaker-cloud itself to ensure all the ancillary dependencies are available. Looking at that is on the plan.

What I should have mentioned for the above question, was that there is already some resilience provided by upstart and systemd in restarting failed daemon processes, and pacemaker-cloud is structured so that there is a separate daemon process per deployable (group of VMs).

Q. I noticed the IP addresses of the VMs change. How do you deal with that?
A. Currently we use a hook to reconfig things as required. I guess you could update DNS also to make it more transparent.
Q. But if you migrate across clouds etc. you could have different routes and everything.
A. Yes, I've not actually done that TBH, but again this would be a hook separate to pacemaker-cloud.