4 ms·

Whereas I am only willing to use a programming language DSL. In any interesting real world case, you are going to run into cases requiring some form of arbitrar

Whereas I am only willing to use a programming language DSL. In any interesting real world case, you are going to run into cases requiring some form of arbitrary logic. Some DSLs will provide you functionality to do loops, ifs etc., but you can't beat a real, actual, programming language.

nihil75 8y ago
So very true. More than once I created scripts that executed Ansible commands (with POPEN, exec and whatnot)..
peterwwillis 8y ago
That's assuming you should be adding logic. The whole idea of CM is to get away from writing programs. Logic adds complexity, is subject to bugs, and is hard to maintain. Most logic I've seen is merely adding procedural code rather than declarative, which is a terrible pattern for a CM. I have worked with nightmarishly complicated Ansible playbooks and roles designed to provide declarative infrastructure when it didn't exist in a module. If all you had to change was a group_vars setting, you could be confident in your change. But if you had to edit a role, playbook or task, nobody was sure if it would break something in the future or not. It was much less robust than a real module because it was just the DSL. With a Python DSL you could write code that was declarative, but because the language is complex, lexing is more difficult, and simple changes to configuration become more error-prone. By moving to images and containers, the majority of configuration management is now largely unnecessary. We will always need a CM tool, but they should give users less rope to hang themselves with, not more.
- mpdehaan2 8y ago
  First off, it sounds like your playbooks sucked - sorry about that, with great power comes great responsibility. Even as I wanted to make things simple, all things could be abused, and in adding more flexibility I've seen some evil things done in my name :) So as immutable systems grow - that's a damn good thing. I personally think the docker ecosystem is a trainwreck currently, but that's only my opinion, and doesn't really affect anyone else. But the same concepts have been around for ages in EC2 in immutable systems. What typically happens is people use the CM tool to provide a higher level abstraction than Bash for describing the image build, so they get features that should have always been in docker files but never were (templates are the biggest one for me). Further, there is always a need to deploy the "undercloud". Even in heavily containerized microservices setups, there's a need to handle all the magic upgrade fun of upgrading a Mongo cluster, a Cassandra cluster, or a Kafka setup. Whether we call it configuration management, app deployment, or just a structured way to push scripts around and see what failed, we're going to need those tools. I believe immutable systems is a fantastic philosophy where it works. It doesn't work everywhere. And CM tools still have a niche for those that want to use them in the build process. If folks want straight docker files instead, I'm also cool with that.

nihil75 8y ago

So very true. More than once I created scripts that executed Ansible commands (with POPEN, exec and whatnot)..

peterwwillis 8y ago

That's assuming you should be adding logic. The whole idea of CM is to get away from writing programs. Logic adds complexity, is subject to bugs, and is hard to maintain. Most logic I've seen is merely adding procedural code rather than declarative, which is a terrible pattern for a CM. I have worked with nightmarishly complicated Ansible playbooks and roles designed to provide declarative infrastructure when it didn't exist in a module. If all you had to change was a group_vars setting, you could be confident in your change. But if you had to edit a role, playbook or task, nobody was sure if it would break something in the future or not. It was much less robust than a real module because it was just the DSL. With a Python DSL you could write code that was declarative, but because the language is complex, lexing is more difficult, and simple changes to configuration become more error-prone. By moving to images and containers, the majority of configuration management is now largely unnecessary. We will always need a CM tool, but they should give users less rope to hang themselves with, not more.

mpdehaan2 8y ago
First off, it sounds like your playbooks sucked - sorry about that, with great power comes great responsibility. Even as I wanted to make things simple, all things could be abused, and in adding more flexibility I've seen some evil things done in my name :) So as immutable systems grow - that's a damn good thing. I personally think the docker ecosystem is a trainwreck currently, but that's only my opinion, and doesn't really affect anyone else. But the same concepts have been around for ages in EC2 in immutable systems. What typically happens is people use the CM tool to provide a higher level abstraction than Bash for describing the image build, so they get features that should have always been in docker files but never were (templates are the biggest one for me). Further, there is always a need to deploy the "undercloud". Even in heavily containerized microservices setups, there's a need to handle all the magic upgrade fun of upgrading a Mongo cluster, a Cassandra cluster, or a Kafka setup. Whether we call it configuration management, app deployment, or just a structured way to push scripts around and see what failed, we're going to need those tools. I believe immutable systems is a fantastic philosophy where it works. It doesn't work everywhere. And CM tools still have a niche for those that want to use them in the build process. If folks want straight docker files instead, I'm also cool with that.