Ahoy, I'm new to this list, so apologies if I violate convention (let me know).
I've been working happily with Ansible for a while, but I've found many AWS modules behave in unexpected ways. Many are excellent, but there seems to be a consistency issue. It's become awkward enough that I just want to replace a few small parts, but I would like to architect them "The Right Way", to avoid problems down the line, in the off-chance that they end up used by folks or even making it back to core somehow. PLEASE give me some ideas / feedback on what would work best if you were designing the modules, or problems you've run into / solved if you already worked on them. ## Current Problems 1. Inconsistency w/ other ansible modules / conventions - e.g. many modules don't offer 'state', 'name' and other common options 2. Nonidempotency - some modules are nonidempotent without a clear reason why, or require you to hardcode a command/action rather than using state (e.g. rds module has command: create, command: replicate) 3. Inconsistency between AWS modules (e.g. ec2 module allows creating attached volumes, but the volume options are different than provided ec2_vol module options) 4. Inconsistency with AWS APIs / boto 5. Inconsistency of module behavior internally for a module task, based on options set (e.g. running ec2 module with exact_count set dramatically changes how the task behaves) 6. Feature gaps - fat modules focused on individual AWS products, seem to make it difficult to perform some actions involving relationships between products. It's surprisingly difficult to do things like modify the security groups of a VPC instance, etc. 7. Large, complex tasks - modules take a lot of options and do many things, leading to confusion, and return values for register variables end up chubby as well 8. There isn't really a good, unified way to target instances of products (like ec2 instances, ELB, etc) that already exist to perform actions on them or to relate them to other instances. ## Ideas Here's my initial idea. Tell me if it's dumb, and why. 1. Start by stealing a few ideas from boto / cli to apply to new modules, such as Filter to select instances to apply tasks to 2. Create a handful of small tasks that perform very specific functions, e.g. `- ec2_security_group_assignment: state=present name=ssh-enabled tag_filter: [ Name: linux-boxes ]` 3. Always use 'state' / 'name' and other common features in modules if possible. 4. Always do idempotent actions if possible. 5. Use more tasks and smaller tasks. (e.g. require `- ec2_instance_option: termination_protection=yes` instead of providing it as option in ec2 module?). 6. Any task that creates / destroys should have the smallest set of options possible, and more detailed configuration should require selection using instance id or filter or whatever. 6. Eventually, *maybe* allow fat tasks to execute smaller tasks for convenience? ## Caveats 1. I'm not really totally happy with any options I have thought up for dealing with idempotency for AWS. 2. It will take me forever to rewrite any useful number of AWS ansble modules. I have almost no time for it and would only be working on scratching the itches that bother me most. Also, I am still a bit baffled by some parts of boto since the switch to boto3 3. I plan on releasing modules on github. I do not plan on trying to get them into ansible core. Anyway, any better ideas for AWS modules? -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
