1. 41
  1.  

  2. 21

    Stop Writing YAMLs! Please.

    1. 3

      But it is not YAML it is based on s-expressions, it looks quite neat actually.

      PS: Oops, only noticed that you’re the OP after posting, so you probably already know this. Sorry.

      1. 4

        Yes, I meant “stop writing YAML for Ansible!” :)

        1. 4

          YAML is the thing I hate about Ansible. The other factor is lack of Python3 support in 2020, but that is fixable, while YAML is there, sadly, by design.

          1. 1

            What do you mean by lack Of Python3 support?

            Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was considered a tech preview. This topic discusses how to set up your controller and managed machines to use Python 3.

            https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html

            1. 1

              I need to try it again. If I’m wrong and there are no longer issues with Python3, all the better!

    2. 8

      How is it an Ansible killer if its own README says, “More viable alternatives include Ansible, Chef and Puppet.”

      1. 3

        Perhaps because this is version 0.1

        1. 4

          It will be a killer. Just give it time :)

        2. 7

          I’m not seeing what this gets me over Ansible, Chef, Puppet, or anything else. The unique selling point of Ansible at the time was that it could be run in an agentless fashion.

          Unless there’s something that this give the world that one of those three doesn’t give us, you don’t have an X killer. It being written in Lisp (which is something that I’m sympathetic to) isn’t even remotely a plus, but an extra barrier, unless it’s been packaged, and even then, it’s a barrier to extension.

          You might have announced it earlier than was wise, but nothing about Adams seems even remotely like it’s going to take configuration management by storm. I’m glad to be proven wrong, and I’ll event stick around after FOSDEM next year for CfgMgmtCamp 2021 if this is even remotely promising.

          1. 3

            How about real programming language for describing configuration, instead of YAML based DSL?

            Lisp provides the power which can be used here.

            1. 3

              Ansible is mostly extensible via Python, though still tied together with YAML. To be completely honest I don’t necessarily agree with the “declarative” assertions that all the modern configuration management platforms claim to have. It’s all procedural underneath, and chances are you’re extending it yourself anyway. IMO Python is probably a “better” language for this type of thing, if for no other reason than more “devops” people know a little Python, but I doubt many know any Lisp. I’ll take anything that gets me out of YAML hell (even though I don’t think YAML itself is that bad), but this project is definitely fighting an uphill battle.

              1. 1

                It is not clear if “the power” here comes from a “real programming language” more generally, or Lisp specifically.

                I think “Ansible killer” is a bit hyperbolic, since Ansible-with-Lisp-for-configuration doesn’t move the needle much for me, and I’m guessing I’m not alone with that. Besides, Ansible (for me anyway) has been dead for a long time. I wouldn’t be considering anything for configuration management that doesn’t compete with NixOps.

                1. 1

                  Doesn’t chef have this? And/or salt? I forget specifics (been happily out of this space for 5 years). But it’s not novel, and it’s also a mixed blessing anyway.

                  1. 1

                    There’s a reason I mentioned Chef and Puppet: you use Ruby for those. Ansible had a USP at the time, but I’m not seeing anything more here beyond what I can get with other existing configuration management tools.

                  2. 1

                    from the description it sounds like you can basically point this at any machine and run this? I think most instrumentation tools (at least Saltstack) require target-machine-side bootstrapping or the like.

                    If these scripts are really “you just gotta point to a machine you have SSH access to”, that’s pretty nifty IMO

                    1. 1

                      Yes.

                    2. 1

                      What got me is the combination of Terraform and Nix. True, it doesn’t work for configuring non NixOS systems, but I don’t have to :)

                      The reasons I like this combination are:

                      • the lack of any markup language in the process,
                      • Terraform has a nice language to describe what needs to be done and supports so many platforms, and
                      • Nix/NixOS is a good enough language that allows me to describe the final system state, and ensure that’s what I’m going to get.
                      1. 1

                        Is it possible to configure the state of the firewall with Nix?

                        Right now I have a “role” in Ansible which is able to open some ports between given machine groups. There I can say, hey, open 80 port to “backends” from “frontends”, and Ansible manages firewall rules for me, to include real IPs into them. This gives me a “virtual private cloud for a pure man” which works across different clouds.

                        What is the easiest way to do something like that with Nix and Terraform?

                        1. 2

                          Yes, of course. However, whether it’s easy, it’s up to the others to say :)

                          I never had to set up something more than open ports. But, the strategy that I use in similar situations is to get the list of IPs from Terraform, and pass them as NixOS module options to the given NixOS deployment. There, I can do anything with that data, as Nix is a full-blown programming language, and I would assume one can set up firewall config.

                          For example, just a couple of days ago, I had to setup Prometheus to scrape several targets, for which I couldn’t use any of the auto-discovery mechanisms. Thus, from Terraform I passed the IPs, then for each IP, I did a cross product with 3 ports that I had to scrape (that was a single line :)). Finally, I added the resulting list to the Prometheus config. When deployed, NixOS generated the correct prometheus.yaml file and started it via systemd.

                          After looking at https://github.com/NixOS/nixos/blob/master/modules/services/networking/firewall.nix#L195, the way to achieve what you want in NixOS would be to manually construct iptable lines and assign to extraCommands.

                        2. 1

                          For practically all of the things my team does at $WORK, we’ve ditched configuration management tools for something similar, but we’ve been using plain old RPM rather than Nix, and a tiny bit of environment-specific configuration laid down by cloud-init.

                          It does the job, and it’s so much less trouble than dealing with configuration management tools, as even the best of them still have you treating your machines/instances far too much like pets.

                      2. 2

                        Seems quite similar to cdist, only that it is written in Common Lisp instead of Python.

                        1. 1

                          Off topic: welcome to lobste.rs! :-)

                          1. 1

                            Thanks!

                            How are you doing, Ivan?

                          2. 1

                            I wonder, how feasible would it be to use Ansible as a backend (i.e. to benefit from the plugins/state transitions/etc), and use Lisp merely to make “writing the configs” part pleasant?

                            Like, I 100% appreciate the effort, but do we really need to rewrite, say, apt module from scratch? Can’t we benefit from the existing, working and tested code?

                            1. 2

                              Well, what do I expect from the new tool is not only easier configs writing but also, better error messages.

                              With Ansible sometimes it is very hard to understand what went wrong. Especially, while you are developing your own roles.

                              I hope this new tool will make this process less painful.

                              1. 2

                                I was thinking about this recently, using a combination of Ansible and Starlark! I find that jinja2 is really limiting and not nice to work with, but using Starlark for example would help tremendously!!

                              2. 1

                                You may also like Propellor, a reasonably mature take on the same idea, in Haskell: https://propellor.branchable.com/

                                1. 1

                                  It would be nice if it’s on quicklisp repositories, would be much easier to try out. Also as I find out while trying to make it work, one of its dependencies re conflicts with a similarly named system. Need more conflicts!!! :D

                                  1. 3

                                    It’s on ultralisp. Did not test it yet though.

                                    Please use repo for pulling dependencies from git.

                                    Or the packaged file adams-0.1-deps.tar.gz on github release page, it’s all BSD/MIT licensed.

                                    1. 1

                                      In Ultralisp too, it’s the same conflict:

                                      [package adams-user].......;
                                      ; caught ERROR:
                                      ;   READ error during COMPILE-FILE:
                                      ;
                                      ;     no dispatch function defined for #\~
                                      ;
                                      ;       Line: 72, Column: 17, File-Position: 2543
                                      ;
                                      ;       Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/abbe/quicklisp/dists/ultralisp/software/cl-adams-adams-20200413010814/core/syntaxes.lisp" {100CF48003}>