I’d like to (again) propose a (backwards compatible) improvement to the module structure, namely a .d directory, e.g.,
copy
copy.d
copy.d would contain advanced usage scripts, such as pre.hook & post.hook (or hooks/pre & hooks/post) and perhaps other stuff that would be run on the overlord before and after execution of the remote module. only ‘copy’ would be uploaded to the far end, just as before.
This would a) allow copy, template, etc to be real modules (not that they need to be at this point, but it would reduce core code in time) and b) allow modules such as copy to perform local operations before running the remote code to, e.g., tar up files to transfer or template. I have an in-house need for this as well, but I think the template and copy modules suffice to show the usefulness of this. I’d be happy to take this on.
Matthew
I’d rather not.
Part of the goals for ansible were to be minimal and small, and I think this is best accomplished by having a Makefile, and the ansible playbook is step 2 in a makefile, and there are steps before and after.
To me, this feels like it’s replacing a makefile or a build system with something that isn’t quite as good at either, which feels weird to me.
Maybe I’m not fully understanding it though.
Cobbler did have a triggers mechanism, which I did like, but that made more sense because it was triggered by async events like systems coming back from registration.
–Michael
I’m just suggesting that some modules need to do some preparation on the overlord side before executing the remote module. I think it would actually simplify the core of ansible, by removing some or all of the ‘special’ modules from runner.
Module authors wouldn’t need to know anything about the .d directory if they didn’t want to. And I think the patch to runner.py would be minimal.
Yeah, I have to say no to some less commonly used features in order to keep things tight.
I don’t see this being useful and it all ads up.
Not to be a jerk here, but I’ve talked to literally hundreds of Cobbler, Puppet, and Chef users over the years… this trigger system does not sounds like something someone
needs.
If you want to push out a package or a tar ball, everybody builds it first.
Ansible is trying to be MORE minimal than those other tools, that’s why it gathered the interest that it has, and I must make sure it’s true to that – so we’re only accepting
new core things that are going to be used by, say, 40%+ of people out there.
–Michael
I’m just suggesting that some modules need to do some preparation on the overlord side before executing the remote module. I think it would actually simplify the core of ansible, by removing some or all of the ‘special’ modules from runner.
Just to clarify this, there are only 3 module side exemptions in runner.
The template module templates locally.
The copy+template module is smart and knows that after running to reuse some code in the file module.
This would just move code out of runner.py and into a script, where we’d lose traceback granularity by calling a script, where instead we can share variables via Python. It’s much more desirable to keep Ansible as a program there, and would also be much faster for not having to execute a lot of new python interpreters.