On Sun, 8 Feb 2015, Brian Coca wrote: > I would ask what is it that you need to do that requires soo much code?
Stuff that'd be expressible (with a little work) as ansible tasks; the installation of some software - but, it ain't via yum or apt. (- Why not just use ansible task lists?) The technology for deployment and installation will change over time; I want to abstract that so consumers writing ansible don't have to _touch_ their playbooks at all if/when our packaging technology choice changes. (- why not use includes?) Considered it; it might still be on the cards, but the include syntax to refer to a shared 'library' is a bit clunky and error-prone compared to a straightforward task name. (That's why I think some kind of macro-definition facility to let ansible give a name to a common series of operations isn't a bad idea - it lets me raise the level of abstraction just enough that my main playbooks are rather more readable.) (- why so much code?) There are a handful of orthogonal concerns: fetching the artifacts to be deployed, FS management, a smidgen of configuration, host-side locking around all these operations. I _could_ slap these all into one honking library/ module but it'd be hard to maintain and test compared to having a handful of stand-alone Python modules that I can use the traditional Python approaches on. (- why not package the code out as a separate installable and ship that out-of-band, invoking that with a stub library method?) That's the route I'm pursuing now. Slight road-bump 'cause AnsibleModule doesn't live in something that I can use as a regular library*, but that's relatively trivial; it's the avenue I'm going down. * I'd hoped to save myself some time with argument parsing and validation, which AnsibleModule does a reasonable job of. Cheers for the attention on this - I appreciate your time. -- [email protected] http://ioctl.org/jan/ Short, dark, ugly: pick any three OORDBMSs make me feel old; I remember when this was all fields.
