3 ms·

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, ch

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?

cookiecaper 8y ago
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.
nihil75 8y ago
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.
- yeukhon 8y ago
  I think Fabric http://www.fabfile.org/ http://www.fabfile.org/ does some of that already.
  - mpdehaan2 8y ago
    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 https://sweetness.hmmz.org/2018-12-18-mitogen-opsmop.html - versus the multiple of SSH operations ansible did per task.
brightball 8y ago
And not to mention being able to utilize Ansible playbooks to build those Docker images too. https://www.ansible.com/integrations/containers/ansible-container https://www.ansible.com/integrations/containers/ansible-cont...
ElijahLynn 8y ago
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-generation-of-configuration-management-tooling-11268b7f21b6 https://medium.com/@michaeldehaan/opsmop-building-the-next-g...
- ElijahLynn 8y ago
  Asked Michael DeHaan on Twitter today about the "Why?" https://twitter.com/ElijahLynn/status/1075446656533811200 https://twitter.com/ElijahLynn/status/1075446656533811200: "Efficiency in both operation (speed) and development of plugins is a big one."
romeisendcoming 8y ago
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.

cookiecaper 8y ago

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.

nihil75 8y ago

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.

yeukhon 8y ago
I think Fabric http://www.fabfile.org/ http://www.fabfile.org/ does some of that already.
- mpdehaan2 8y ago
  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 https://sweetness.hmmz.org/2018-12-18-mitogen-opsmop.html - versus the multiple of SSH operations ansible did per task.

brightball 8y ago

And not to mention being able to utilize Ansible playbooks to build those Docker images too. https://www.ansible.com/integrations/containers/ansible-container https://www.ansible.com/integrations/containers/ansible-cont...

ElijahLynn 8y ago

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-generation-of-configuration-management-tooling-11268b7f21b6 https://medium.com/@michaeldehaan/opsmop-building-the-next-g...

ElijahLynn 8y ago
Asked Michael DeHaan on Twitter today about the "Why?" https://twitter.com/ElijahLynn/status/1075446656533811200 https://twitter.com/ElijahLynn/status/1075446656533811200: "Efficiency in both operation (speed) and development of plugins is a big one."

romeisendcoming 8y ago

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.