The Mgmt configuration management language

I hope that the DSL evaluator can statically determine the oldest historical value that the code will use and avoid keeping unused historical values around?

FRP has a more general purpose way to do that kind of thing; a behavior can accumulate occurrances of an event, using a function provided by the user that takes the previous accumulation and adds a new value to it. This makes it easy to implement things like a rolling average, or to access historical values without keeping unnecessary ones around.

For example, here's a rolling buffer of size n in haskell's reactive-banana:

    rollingbuffer n event = accumB [] (fmap update event)
      where
        update v l
            | length l < n || null l = v : l
            | otherwise = v : init l

Of course, this needs a language that functions can be implemented in, not a special-purpose DSL.

Language is a human invention allowing humans to express ideas. But language often masks the complexity of systems. If I told you "put the jar on the counter", there is a lot embedded in that language, but also a lot is missing, and it's up to the human to make decisions based on its life experience to figure out how to interpret that command in each circumstance. If you've had any experience at all in a configuration management DSL, you know that after a while, they all just suck to use.

And it's mostly the same problem for programming. With programming we're using language to express a complex set of interactions, but we still often fail to catch important distinctions, and most of our code does not learn from its past experience. Language can express complex ideas, but only if you have a brain that can re-interpret the language continuously and act differently in each case. That is the hope of language-based configuration management, but rarely do you see a CM tool that is fed regular data solely so it can change how it makes decisions.

I think modeling languages like TOSCA are a much better design for expressing how to manage a complex system. By modeling the components and interactions, it's much easier to observe and test for various conditions in simulation. You can get incredibly detailed in modeling, and as such it's much easier to manage all the complex interactions, rather than hoping you are good enough at language to be able to express your ideas in a way that will be interpreted the right way by an otherwise rigid computer program.

Mgmt looks awesome. It's just a shame it arrives so late, when stuff like containers and orchestration systems (read: Docker and Kubernetes) is taking over lots of responsibilities traditionally left to configuration management.

Not to say configuration management and traditional servers are going away within the next years, but it will probably hinder the popularity and growth of new tools like these. Sadly.

I worked with James a bit at Red Hat. He's a smart dude and I look forward to following his progress with this post-RedHat life.

So it is like React but for server management, and using it's own functional reactive language [1].

That's super cool! I definetly will keep an eye on it.

I would have preferred a more standard language, but I guess it's difficult given the problem space. Actually looks easier to understand than force feeding yaml into ansible.

[1] https://en.m.wikipedia.org/wiki/Functional_reactive_programm...

I eventually want to create a something similar to mgmt but with separation of concerns, the language would simply get compiled into an idempotent shell script that would use POSIX CLI tooling. The issue with doing this is I don't know many languages or compiler frameworks that compile down to shell (if any).

So this is rediscovering Puppet's language. OK, and what's new in here?