Having big Jenkins cluster requires monitoring many things. Lately we started saving information about what build ran on which machine and when. Jenkins actually provides that feature, this is called “Build history” and can be seen for the whole cluster or for some particular node. Unfortunately, when cluster is quite big (ours has more than 300 executors serving more than 10000 builds per day) Jenkins is not able to show the graph.
I gave a talk lately at DevClub about vim autocompletion out of the box and registers. Sorry, english-speaking friends, the talk is in Russian.
Lately as a process of joining different Postgres databases with 1 schema each into 1 database with different schemas, I had to export a schema from a database and to import it into another database with a different schema name.
Ruby standard library provides a good solution for parsing command line options passed to the script or application. It’s called OptionParser. It’s powerful and very easy to use. The code you have to write is easy to read and modify. It also supports different kind of options: short and long flags, required or optional arguments, also different types of arguments including dates, lists and so on.
My work involvs writing many small command line applications (scripts) in ruby. One of the common things among them is logging. The application should produce adequate log messages, so that one could follow the application flow. Ruby has a very good logger in standard library. You can use it like that:
Testing your cookbooks with unit tests will help you not to break existing functionality. But how can you be sure that the recipe will successfully run on production node? The only answer to that is running this recipe on some other/similar machine and checking if everything is actually configured the way it must be. Don’t worry we will not need some additional hardware for testing cookbooks, it can comfortably be done in virtual machine or container.
Before going further to running integration tests on your cookbooks and roles we need to prepare a bit by creating an Lxd container, where we would run our tests. This is a script that creats an Lxd container with Chef installed and a running ssh server (required for Test Kitchen transport).
I decided to start blogging again. Somehow I felt necessary doing that not for someone else, but for myself. It’s a good way to organise my own knowledge and thoughts.
Disclaimer: as of Jan 4 2014, this is already implemented inside ChefSpec (>= 3.1.2), so you don’t have to do anything. The post just describes the problem and solution with more details.
Last time we were speaking about testing Chef recipes, I introduced to you ChefSpec as a very good tool for running unit tests on your cookbooks. But lately I encountered a problem with it. I have over 800 unit tests (aka examples in RSpec world) and now it takes about 20 minutes to run. 20 minutes, Karl!!! That’s a extremely long time for this kind of task. So I decided to delve, what exactly is responsible for taking so much time.
I always thought that it should be a trivial task. There are even some stackoverflow answers on that topic, but there is actually a catch that none of the answers talks about.