Opening remarks All my previous posts were about choreography, deployment, topology, and more recently about an attempt to include AI in those systems. This post is a bit apart, because I’m facing a new challenge in my job which is to implement BDD in a CI chain. Therefore, I’m using this blog as a reminder of what I did personally. The following of the Markov saga will come again later.

Introduction Opening remarks I’m not a Ruby developer, and I’m heavily discovering the ecosystem by now. This are my notes, and if anything seems wrong to you, do not hesitate to send me remarks. The scenario For testing purpose, I wanted to play with vagrant-aws and more generally with ruby on my Chromebook. Vagrant does not support rubygems as installation method anymore (see Mitchell Hashimoto’s post) and of course, there is no binary distribution available for the Chromebook.

Introduction In my last post I introduced the notion of choreography as a way to deploy an manage application. It could be possible to implement self-healing, elasticity and in a certain extent self awareness. To do so, we must not rely on the certainty and the determinism of the automated tasks. Mark Burgess explains in his book in search of certainty that none should consider the command and control anymore.

Thanks to the company I’m working for (Techsys) I’ve had the opportunity to attend the configuration management camp in Gent (be) for its 2016 edition. I really enjoyed those two days of talks, watching people present different ideas of a possible future for the infrastructure and deployment engineering. Beyond the technical demonstrations and the experience sharing, I’ve spotted a bunch of ideas Among all, those that comes to me spontaneously are:

I’ve read a lot about graph theory recently. They have changed the world a lot. From the simple representation to Bayesian network via Markov chains, the applications are numerous. Today I would like to imagine a graph as a workflow of execution. Every node would be considered as runnable. And every edge would be a dependency. It is an important framework that may be used to as an orchestrator for any model, and of course I am a lot thinkingabout TOSCA

From time to time, I’m involved into a trolling conversation when any linux kiddie tells me: Bash is really the superior shell I totally disagree, but as I’m getting older, I don’t argue anymore. Anyway, in this post I will expose two arguments, or I should say two reasons, why I usually use ksh93 to run my scripts. Note I’m really talking about the engine of the script, (the shebang definition).

About TOSCA The TOSCA acronym stands for Topology and Orchestration Specification for Cloud Applications. It’s an OASIS standard. The purpose of the TOSCA project is to represent an application by its topology and formalize it using the TOSCA grammar. The [TOSCA-Simple-Profile-YAML-v1.0] current specification in YAML introduces the following concepts. TOSCA YAML service template: A YAML document artifact containing a (TOSCA) service template that represents a Cloud application. TOSCA processor: An engine or tool that is capable of parsing and interpreting a TOSCA YAML service template for a particular purpose.