I can create an AWS EC2 instance with the ‘ec2’ module and a unique ‘id’, and Ansible skips creation if an instance with this name already exists. This feature doesn’t seem to exist in the ‘rds’ module.
Any suggestions how to check for existence of an RDS and only create if it doesn’t exist?
Thanks.
You probably ought to look into using AWS Cloudformation for AWS resource
creation - Ansible has support for it, and it handles things like this very
well.
I believe you missed my memo on “the world says idempotent too much” 
Can you share what happens when you run it again, showing “-v” from the ansible-playbook run?
For the time being you can use command=facts to see if it already exists and only use command=create if it doesn’t.
-Bruce
BTW, if this is creating a second, please file a bug.
+5 ansible points for not saying “idempotent” in the ticket
Does Github have an idempotent API for creating tickets?
Fuzzy ticket matching might be lucrative.
Ah, that ‘facts’ command should work.
Without a check like this, it will detect the existing instance and fail with:
msg: DB Instance already exists
@Michael, yeah, I just started catching up on the group and then read The Memo
Thanks, all.
I’d rather have the RDS module upgraded.
CloudFormation requires writing some messy JSON, where as Ansible is a lot more friendly when using modules directly.
I agree some others may disagree.
If all you're doing is creating an RDS instance, then yes, absolutely CFN
isn't ideal.
I’d be more than happy to improve the rds module. The question I have is what’s the best approach to take. The problem, as I see it, is that the rds interface is rather complex, so trying to distill it down for Ansible has the potential to be rather tricky. There are a number of both required and optional parameters when you create a database. What should the module do, for example, if you try to create a database with the same name but vastly different parameters?
When you create a database you need to specify the name, type of database (oracle, mysql, etc), the disk size for the data store, the cpu/memory size of the server, and the root username/password. Suppose you already have an oracle database named “foo” and you then call the rds module to create a mysql database named “foo”. I would argue that this should generate an error of some sort and not simply return changed=false since the underlying database is vastly different than what you requested. But what about something like disk size? Should it trigger an error if you try to create a database where all the parameters are identical to an existing instance but the size is off by a gigabyte? And then there are all the optional parameters like backup_window. If you don’t specify a backup window then Amazon will randomly assign one, so should any ‘changed’ check simply ignore parameters like these?
Similar issues arise with regards to the ‘modify’ command since there are different ways it can be applied. If you tell AWS to increase the size of your database you can tell it to apply the change immediately or you can defer that change until the instances next maintenance window, at which point it will reboot & resize the database automatically. How should cases be handled where there are conflicting modifications requested? Suppose you issue a command to resize your database to 200 gig during the next maintenance window, then before that maintenance window you run a play that tries to resize it to 250 gig immediately? I’m not sure if the AWS API even supports modifying/deleting pending events. I just did a quick check of boto and it doesn’t seem to have that capability.
-Bruce
Been googling around for the idempotent memo you mentioned - anyone have a link? (or maybe it was a joke and I’m a little clueless?)
Ah, here: https://groups.google.com/forum/#!msg/Ansible-project/WpRblldA2PQ/lYDpFjBXDlsJ
I should have totally added another paragraph on “imperative” and “declarative”
Excerpts from Matt Jaynes's message of 2013-11-27 13:58:10 -0500:
Been googling around for the idempotent memo you mentioned - anyone have a
link? (or maybe it was a joke and I'm a little clueless?)
See, it's clear that this mailing list is not nearly idempotent enough!
It should be obvious that the mailing lists can be modeled as
a surjection from the set of senders to the set of mailing lists.
We should rewrite it in node.js to make sure it's web scale. Then we'll
be able to make sure our NoSQL databases are cloud-ready.