3 ms·

If anyone modifies this thing to use real YAML (not whatever Ansible was passing off as YAML) or HCL as the configuration file format, please post it to HN? I'm

If anyone modifies this thing to use real YAML (not whatever Ansible was passing off as YAML) or HCL as the configuration file format, please post it to HN? I'm never going to use a programming language DSL. What I really want is a real document standard that describes common configuration management functions, and then implement a parser in every CM tool, so all of them can do the same basic functions with one standard file. Like a k8s file that can describe Terraform-like modules/providers/resources, and each CM can have it's own implementation to build, test, and apply them. As an aside, we really aren't using YAML to its full potential. We could benefit from an implementation of YPath so we can work with YAML files the way we use XPath with XML, and tags are greatly underutilized.

rkangel 8y ago
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.
mpdehaan2 8y ago
"(not whatever Ansible was passing off as YAML" It at least was parseable. The trick was, it was always supposed to be at the level of complexity of "grocery lists, but..." ... but frequently I think people tried to program in it a little hard. OpsMop is based on the idea of a cyborg system - writeable for humans, but easy to interface with machines. I take some alternate views, and believe YAML is best kept streamlined, which is why I also did not use YAML anchors in ansible.

rkangel 8y ago

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.

mpdehaan2 8y ago

"(not whatever Ansible was passing off as YAML" It at least was parseable. The trick was, it was always supposed to be at the level of complexity of "grocery lists, but..." ... but frequently I think people tried to program in it a little hard. OpsMop is based on the idea of a cyborg system - writeable for humans, but easy to interface with machines. I take some alternate views, and believe YAML is best kept streamlined, which is why I also did not use YAML anchors in ansible.