This is the first post in what’s going to be a multi post series exploring how MQTT can be leveraged in the cloud. The series will look at several different models for deploying applications in the cloud and how you can leverage MQTT as an event based protocol for those applications. This first post will be looking at using MQTT as unified event bus for heterogeneous service deployed using more traditional configuration managed services by looking at the OpenStack community infrastructure’s firehose effort.
For the past year and half I’ve been working on a parallel test runner for python tests, stestr. I started this project to fit a need in the OpenStack community and it since has been adopted as the test runner used in the OpenStack project. But, it is generally a useful tool and something I think would provide general value for people writing python tests. I thought it would be valuable to explain two things in this post, first the testing stack underlying stestr and the history behind the project. The second aspect is how it compares to other popular python test runners are out there, and the purpose it fills.
I recently built a new home server, it’s a multipurpose box that will hold most of my infrastructure and also is a file server with a lot of hard drives (and room for more in the future) All of these drives meant this ended up being a very large machine so there was space to put them all. I ended up getting a CaseLabs Magnum THW10 for the case, which has space for a ton of stuff in it. While the machine is working great and doing everything I need it to, there is one small problem with it. The front fans aren’t spinning fast enough.