mitogen-hq
Is Mitogen still under development and supported? How can the community help?
Hello,
I'm sorry to have to ask the question, especially as I've personally not contributed and currently limited on time to do so; However do the maintainers of this this project plan to continue development into the future to keep up with Ansible releases ? Respond to PRs?
If I were to contribute, is there something specific that myself or others could help with to make future releases a reality?
Is there conflicts in the design between mitogen and later versions of Ansible that make it hard to integrate with, I'm only just across the problem with collections in 2.9+.
Thanks for all the hard work so far, Mitogen has saved me many hours waiting for otherwise painfully slow Ansible runs.
Hey there. Regarding pull requests, it would probably help to get more contributors with the ability to review and merge. Including myself (presently inactive) we only have Steve and Alex, neither of which are supported in their work. Alex has been active over recent days working on some pulls, I will also try to step up and help clear some of the current queue.
While I still maintain a strong interest in the core library, I personally no longer use Ansible and nowadays unconditionally migrate clients off it. There shouldn't be any technical reason why the extension cannot be updated, the major barrier has always been time and dedication.
As for its future, playing continuous catch-up with an uncooperative upstream was never a desired outcome. It has long been evident that project's problems aren't contained to the connection layer or indeed even its codebase, and many limits have been discovered on what can be fixed by an extension. Overcoming that is possible because strong demand exists, but doing so involves greater commitment than justifiable, for an unchallenging outcome that is far from originally intended.
I would be interested in helping out review PRs. Let me know what would be required to help.
As a side note, I would be interested in why you stopped using Ansible and what you have migrated too.
While I still maintain a strong interest in the core library
Dear @dw,
Sorry about an out-of-topic question: Are you still working on Operon? Any update? https://networkgenomics.com/operon/
Hello all, Sorry for the slow responses. I'm trying to catch up with the backlog. I'm not using Mitogen as much, so I'm afraid my attention is sporadic.
@apple4ever thank you, I'm still very new to being a maintainer on a project I didn't start. I don't feel confident enough yet to say do this, or do that.
why you stopped using Ansible
It's a conceptual liquid hairball, it markets the ability to do everything and in the process gets nothing right. After a decade almost every component you could examine is still terminally underdeveloped, even the documentation is still a Geocities-esque disaster. Conceptually, manipulating APIs which comprise the vast majority of a contemporary infrastructure environment with the only model it offers nets volumes of unsafe and verbose code. It's basically a really bad take on bash, with the addition of forced toil on basically every upgrade.
It is not beyond rescue, but given the project's pace, it could easily be at least 5 years behind where it should be from a design rigour and implementation perspective, if it were even a priority. Software often acts as a mirror to understand the culture and values of its origin, and the momentum supporting the project means such work may simply never happen. That it is still possible to find functions like this or this right at the heart of the system after so long is all any engineer really needs to know about it.
and what you have migrated too
For apps, Dockerfiles and often some shell scripts
For hard infrastructure orchestration, in most recent project Amazon SSM and would definitely use it again. SSM avoids inventing a new language which is neither ugly but practical (bash) or safe and carefully designed (Python), and comes with AWS-level backwards compatibility enshrined in its API contract.
For software orchestration, in most recent project ECS+ECS Anywhere. I've toyed with Kubernetes but dislike the complexity, it's not really possible to use it unless there is a dedicated Kubernetes person left behind to run it, which completely defeats the purpose, even with managed controllers (EKS, GCS). Kubernetes is basically yet another forced toil generator, and the YAML can almost be as liquid as Ansible YAML. I'd like to try Nomad, but the docs suggest a different story about complexity than the marketing. ECS is roughly the ideal level of complexity, but its lack of some features by default (service discovery, PVCs) sucks.
For cloud stuff, Terraform, although it can suffer similar syntactic verbosity deficiencies as Ansible, and borrows the same attitude towards backwards compatibility. Graph-oriented infrastructure descriptions have some major downsides but they also feel like the right model. I've been bitten repeatedly by Terraform upgrades so it's not a tool I fully trust, but for this use case it still seems the best option available at present.
I'm happy with relying on many tools. Maybe some ideal single infrastructure/deployment multi-tool is possible, but at least for the moment the idea and its manifestations seem attractive nuisances. There are some interesting attempts to turn Kubernetes into a grand multi-tool, but having the complexity of k8s as a baseline would already seem to make these complete non-starters.
I dislike relying on AWS, but their culture around internalizing toil suits my mode of work very well. If only some free software solutions (other than bash!) existed with similar stability.