The trick was, it was always supposed to be at the level of complexity of "grocery lists, but..." ... but frequently I think people tried to program in it a little hard.
OpsMop is based on the idea of a cyborg system - writeable for humans, but easy to interface with machines.
I take some alternate views, and believe YAML is best kept streamlined, which is why I also did not use YAML anchors in ansible.
My historical argument was always that if a playbook looks ugly, it is wrong.
Over the years I haven't been around to keep saying that, but I'd be inclined to have to find ways to open up the programming model while still keeping the mostly organized guide-rails in place.
I suspect people will probably adopt it if they like it mostly for new projects.
We still do have a lot of modules to write yet, so if you are interested in that, stop by talk.msphere.io - I'm open to a lot of enhancements there, but also want to keep it somewhat controlled.
A lot of the early adoption is no doubt going to be folks doing CM-based builds for images (EC2, docker, whatever), where everything remains pretty disconnected.
A mid-way adoption stage might be using opsmop to run existing ansible content, though ... that's really pointing towards wanting to add something like rsync, which is easy, but... I need to think about that a little bit.
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.
Righto (author here)! It's a lot more relaxed (IMHO) than some. Most methods are raw python. The "set_foo" methods are just methods that get called when the objects are constructed to populate certain fields. You can just pass those in and leave them off if you want.
There's a fair amount of that available in http://docs.vespene.io/importing.html ... if you have more ideas can you stop by https://talk.vespene.io/c/ideas ? ... I don't want to make the syntax more complex than the YAML that is there now, but I think we can add other fields if there is something you want or a capability that might be missing.
While you're welcome to that opinion, Django has been freaking awesome. This whole thing got written in 3 months, not even working full time. I wrote pipelines in like a day.
It seems like you're saying I should have used a many-to-many there rather than 7 FKs. Probably, but shrug... it can be fixed later if it ever becomes a problem.
There really aren't any liabilities any more so than in violating the GPL, and people have been over that for eons. Don't sell it without joining the partner program, more or less. Rates are posted, it's cheap, and helps support the upstream.
At least, I don't think I'm evil. Some people might not know me, but I don't feel evil :)
It at least was parseable.
The trick was, it was always supposed to be at the level of complexity of "grocery lists, but..." ... but frequently I think people tried to program in it a little hard.
OpsMop is based on the idea of a cyborg system - writeable for humans, but easy to interface with machines.
I take some alternate views, and believe YAML is best kept streamlined, which is why I also did not use YAML anchors in ansible.