Hacker News Reader

Comment by sciurus | Hacker News Reader

The question I don't see answered anywhere on their website or repo is "why?". Why in 2018 with

a) many mature configuration management systems like puppet, chef, ansible, and salt

b) lots of architectures that no longer require traditional configuration management (e.g. "serverless", immutable deployments of VM images, docker images on hosted kubernetes)

is there a need for a new CM tool? What is OpsMop doing different or better that gives it a hope of gaining traction?

View on HN

Michael DeHaan, creator of Ansible, wrote an intro here:

OpsMop: Building the Next Generation of Configuration Management Tooling ==> https://medium.com/@michaeldehaan/opsmop-building-the-next-g...

Asked Michael DeHaan on Twitter today about the "Why?" https://twitter.com/ElijahLynn/status/1075446656533811200:

"Efficiency in both operation (speed) and development of plugins is a big one."

From an initial glance it seems OpsMop is more of an extension of Python than a stand-alone tool built using it.

I think OpsMop allows you to create Python scripts that include deployment tasks along with "standard" code.

An interesting approach in my opinion.

I think Fabric http://www.fabfile.org/ does some of that already.

Ok, so Fabric did exist even way back in 2012 when I did ansible.

The common pattern of the day was to use Puppet to do OS config management and then Fabric to push out the apps.

Fabric lacked declarative resources to describe the desired state of the end system, which is where Ansible came in.

Ansible differed because it still allowed direct control over multi-machine orderings, which is (IMHO) easiest in push modes, so it was kind of (IMHO) the best of both worlds access models.

OpsMop has the same kind of push model, still keeping the declarative resources, it's just all Python.

However, on the remote end, it uses mitogen, so very efficient RPC ops (1 per role + files) - https://sweetness.hmmz.org/2018-12-18-mitogen-opsmop.html - versus the multiple of SSH operations ansible did per task.

on b -- if you're building containers and other "immutable infrastructure" correctly, you're still using CM. That so many think a Dockerfile accomplishes the same things is a testament to how poorly most of us understand what we're doing.

And not to mention being able to utilize Ansible playbooks to build those Docker images too.

https://www.ansible.com/integrations/containers/ansible-cont...

Tools which are basically dumbing down a generation in exchange for efficiency at scale. The day will come when provided with three whiteboxes, install media, switch + cabling -- there will be a lot of nothing going on.

Or - better yet: the blue collar guys do that.

Reply on news.ycombinator.com