3 ms·

The Mgmt configuration management language

51 points by networked 8y ago

peterwwillis 8y ago
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.
dmoreno 8y ago
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_programming https://en.m.wikipedia.org/wiki/Functional_reactive_programm...
hexdrop 8y ago
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.
joeyh 8y ago
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.
raziel2p 8y ago
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.
nwmcsween 8y ago
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).
- senorsmile 8y ago
  I had a sort of similar idea a long time ago. I even came across a few that do something similar to what you are describing.
  - nwmcsween 8y ago
    Thinking about it more it could be simplified to just be an execline script and separate binaries for 'package', etc.
dozzie 8y ago
So this is rediscovering Puppet's language. OK, and what's new in here?
- robbyt 8y ago
  And doing so while ignoring several years of thoughtful iteration and design by the team at Puppet... This looks like Puppet language circa 0.24.
- networked 8y ago
  The language is inspired by Puppet, but reactive and statically typed. The configuration can depend not just on current, but on historical observations about the system, and is applied continually. I think the QEMU example in the article illustrates it well. Edit: Puppet has what it calls "data types", but they are not checked statically. $ cat test.pp function f(Boolean $arg) >> String { 5 } if false { f("not a Boolean") } $ puppet apply test.pp Notice: Compiled catalog for foo in environment production in 0.03 seconds Notice: Applied catalog in 0.02 seconds

51 points by networked 8y ago

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.

dmoreno 8y ago

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_programming https://en.m.wikipedia.org/wiki/Functional_reactive_programm...

hexdrop 8y ago

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.

joeyh 8y ago

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.

raziel2p 8y ago

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.

nwmcsween 8y ago

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).

senorsmile 8y ago
I had a sort of similar idea a long time ago. I even came across a few that do something similar to what you are describing.
- nwmcsween 8y ago
  Thinking about it more it could be simplified to just be an execline script and separate binaries for 'package', etc.

dozzie 8y ago

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

robbyt 8y ago
And doing so while ignoring several years of thoughtful iteration and design by the team at Puppet... This looks like Puppet language circa 0.24.
networked 8y ago
The language is inspired by Puppet, but reactive and statically typed. The configuration can depend not just on current, but on historical observations about the system, and is applied continually. I think the QEMU example in the article illustrates it well. Edit: Puppet has what it calls "data types", but they are not checked statically. $ cat test.pp function f(Boolean $arg) >> String { 5 } if false { f("not a Boolean") } $ puppet apply test.pp Notice: Compiled catalog for foo in environment production in 0.03 seconds Notice: Applied catalog in 0.02 seconds