Jorge Cardona


Twitter Google+ Github

There is nothing interesting in this post just some personal ideas to not leave them in the back of my brain.


I have been using puppet for a while, and I don’t like it. It seems that I just turning a mess into another.

I will try first to state the things I like:

  1. I like the descriptive language.
  2. Facter.
  3. Some types are pretty nice. Just some of them.

And I don’t like:

  1. The way to evolve my configuration, it seems normal to use a versioning system for this, but this doesn’t give me any advantage since there is no a structured way to describe a new set of configurations.
  2. Third-Party Modules, I hate to include code to my repo just to have more types, there should be a central repo and a import system without adding code to mine.
  3. Some types are just non-functional, like rabbitmq.
  4. It promise to solve my problems, but is just turning in a new problem.
  5. There is some assertion in some bug report that says that if I have too much execs in my puppet is because I need a new type, but the type is there, is just that is not working properly.
  6. It doesn’t fit pretty well with highly changing configurations.
  7. Don’t like to go around with all my puppet config in all my servers, and deal with separate puppets for each type of server add too much overhead.
  8. At the end is easy to use just execs and augeas to configure must of the things if the correct type doesn’t work, and this seems to be a bad practice, but the good practice is a non-working practice.
  9. Debugging is horrible.

So, basically I just like the descriptive language, facter and some nice (obvious) types.


I haven’t use this, but it seems nice, also it seems they are just reinventing the concept of packages and adding an explicit way to define how to expose and consume services with the charms. It seem similar to debian cmdb: My system knows that x-www-browser is the way to exec-consume the program-service “graphical browser”, and each package able to expose it is going to point to this, and you can select the correct service-program with update-alternatives.

I think that debian packages are prety overwhelming, I have build some packages in the past and compared with python packages is like learning to fly an plane. So, definitively packaging needs a fresh air.

CMDB as packaging

So, given that there is a obvious way to describe service in consume-exposing also dependencies between packages, there is a natural way to create a graph with this relations. I have been trying to build something like this in Espresso with no success.