Here’s the video of my ignite talk at Config Management Camp 2016: “the three legs of modern configuration management (…or maybe it’s four)”. The slides of the talk are also available on SpeakerDeck.
Here’s the video of my ignite talk at Config Management Camp 2016: “the three legs of modern configuration management (…or maybe it’s four)”. The slides of the talk are also available on SpeakerDeck.
It didn’t take many hours for Luke Kanies to pick up my provocative blog post and express his disappointment:
@brontolinux @duritong I love this kind of shit. From the market’s perspective, we were never relevant, now we’re obsolete
— Luke Kanies (@puppetmasterd) 15 Febbraio 2016
I’m not going to complain for his words: if I was him I would have thought the same things, and maybe also written the same things. At the same time, it’s kind of funny that a lot of the inspiration for that post came from Luke himself. I’ll explain.
CFEngine, Puppet, Chef… and Ansible, Salt… and many others. We have loved them and we have hated them. It’s time we take a picture, because they may be gone in a few years time. This is the word — or the cry — that got out of too many Configuration Management practitioners at this year’s Config Management Camp.
As the title says: the code for cf-deploy is now on github. Please ensure you read the README to understand the current limitations, and please help improving the tool.
The thing it’s lacking most is an external configuration file. Other useful additions could be Makefiles to support different version control systems other than git, and tools other than rsync for deployments.
Enjoy!
The Config Management Camp 2015 is gone leaving its trail of inspiring presentations, interesting discussions, pleasant meetings with great people and, hopefully, satisfaction for how each of us has played his/her part to make this edition a success.
A big thank for the brave people that attended my seminar and to those who asked questions. The questions gave me a couple of ideas to further expand the seminar, and more may come if you’re so kind to let me know your opinion on the talk: what you liked, what you didn’t, what could be improved in both the talk and the speaker’s style. Thanks in advance. As for the code of the tools, I promise to publish it on GitHub as soon as I get “clearance” (this week, possibly!).
For those who weren’t at the seminar, I presented how we evolved our git repository structure to support more than one project, each one with its own needs, but at the same time being able to share the relevant common libraries and tools and to make the deployment of the policies easy, manageable and maintainable, whatever the number of hubs and projects involved. The questions dove nose down to how we manage access to the hubs so that a person working on project A can’t accidentally deploy his policies on the hubs supporting project B, how we manage access rights to files in separate projects and to branches, and how easy or hard is to extend the deployment tool with new functionality.
The slides of the presentation are on SpeakerDeck (or further down the post if you don’t bother go to SpeakerDeck 😉 The good guys at Normation also filmed the seminar, so it’s just a matter of time that a video of the seminar will be available. Then you’ll also be able to hear my appeal to support cancer research, talking of which you can check another blog post of mine.
Regarding the talks I attended and the “hallway track”, Jez Humble’s keynote was definitely a mind blowing experience. Leaving aside the things that I am doing wrong, that we are doing wrong in my work environment, and that a broad set of people in our profession is f***ing up completely, I understood that there is a category that definitely needs to be more present at events like this: bosses. Because we can do a good job as professionals, follow the best practices, use the brightest and shiniest tools of today and some of the tools of tomorrow, but that’s definitely not enough to establish a culture of cross-area collaboration. That’s not going to happen without the direct involvement of the bosses and their mandate.
I’ve written this post on the plane on February 4th while going back from Gent to Oslo.
It’s some time that February 4th has a special meaning for me. No, it’s not my birthday, nor my wife’s, nor anyone I know’s birthday. February 4th is the World Cancer day and yes, you should care, too.
It’s not necessary to get the illness to understand the importance of cancer research. I’m not ill, but my father died of cancer in 2012, aged 69; or maybe I should say that cancer ate him, bite by bite, breath by breath, literally. And while I’m grateful for what he was able to do for us, his family, during his illness, it hurts. It hurts that the only way to save him was to catch the disease very early and attentively follow-up, not give a chance, because if the disease manages to spread a bit, you’re screwed. And that’s because there were only three different medicines for his type of cancer, and none could save his life. Research has gone only that far.
There is only one thing that I can do to give one more chance to the people I love, my wife, my son, or even myself: help cancer research to advance before cancer takes a chance on one of them. That means donations to cancer research foundations in your country or, as we discussed at the Configuration Management Camp (yes, there, it’s not a mistake), do what we can do with our expertise to facilitate cancer research. While we get going with a plan for a good initiative that tech people can help with, I bet you. I want you to bet against me and against cancer.
Last year I ran two 10km races in Oslo, both on a pace of 6’40″/km (slooooooooowww!!!). I plan to run more 10k races this year, the problem is that I’m not in a good form because I had to reduce the training to focus a bit more on my running technique. As of today, I don’t even have “the distance in my legs”, so to say, and the pace is even slower than 6’40”. That’s a good context for a bet.
I bet that I’ll run the Sentrumsløpet on April 25th at a pace better than 6’40”, and I want you to bet against me. If I make it, then you make a donation to one of your country’s associations that support cancer research. If I lose, then I’ll donate 1000 NOK to Kreftforeningen (but please feel free to make a donation anyway 😉
Who’s in? Let me know by commenting this post.
The first half of February is going to be quite busy to me with two conferences just a few weeks away now.
On February 2nd and 3rd I’ll be at the Configuration Management Camp in Ghent, Belgium, where I’ll hold the seminar “Many projects, one code” on the 3rd. A little more than a week later, the 12th of February, I’ll then be at Software 2015 in Oslo, where I’ll hold the seminar “The classification problem: challenges and solutions” in the Continuous delivery and DevOps track. And yes, the slides will be available on my SpeakerDeck account as soon as a seminar is done.
Update March 1st, 2015: the latest version of the code for hENC is now on github
It’s been about a month since I came back from FOSDEM and cfgmgmtcamp, a month where I gradually recovered from the the backlog both in the office and at home. It’s been a wonderful experience, especially at cfgmgmtcamp, and I really want to thank all those that helped make it special — more details at the end of this article.
But promise is debt (no pun intended with promise theory here), and I promised to write a long blog post with some (or all) the details from my talks. It’s time to keep that promise. So, without any further ado…
While checking once again my sources before publishing a “transcript” of my seminars at FOSDEM and cfgmgmtcamp, I found out that something in the way I presented LinkedIn’s ENC didn’t sound right. I contacted Mike Svoboda and, unfortunately, he confirmed that I actually mixed up two different things.
What was right: their ENC solutions is actually based on Range, as Mike himself explains in this post in the help-cfengine mailing list. It is also true that Range collects information from many different sources, including sources defined outside of the System Operations group, and makes that information available to nodes. In turn, the nodes use that information for classification by means of bash and python scripts.
What was wrong: the system illustrated by Mike in his seminar “Leveraging In-Memory Key Value Stores for Large-Scale Operations” is separate, and someway complementary, to the ENC system, and is implemented using Redis. Mike has published the details about it in the help-cfengine mailing list.
Apologies for the mistake 😦