Thanks for the ideas. I took another look at this using the rds
module's 'wait' and 'wait_timeout' arguments and realized that they
did what I wanted after all. When the instance setup is complete and
it goes to available status, the task immediately completes - and
these set a maximum amount of time to wait for it. Sorry for the
noise, I didn't need to overcomplicate it after all.
I ended up with this task:
- name: "provision rds instance (timeout: {{ rds_instance_deploy_timeout }}s)"
become: no
local_action: rds
args:
command: create
instance_name: "{{ rds_instance_name }}"
instance_type: "{{ rds_instance_class }}"
vpc_security_groups: "{{ rds_instance_vpc_security_groups }}"
multi_zone: "{{ rds_instance_multi_zone }}"
subnet: "{{ rds_instance_subnet_group }}"
db_engine: "{{ rds_instance_engine }}"
publicly_accessible: "{{ rds_instance_public }}"
maint_window: "{{ rds_instance_maintenance_window }}"
backup_retention: "{{ rds_instance_backup_retention }}"
size: "{{ mysql_app_db_size }}"
db_name: "{{ mysql_app_db_name }}"
username: "{{ mysql_admin_user }}"
password: "{{ mysql_admin_pass }}"
wait: yes
wait_timeout: "{{ rds_instance_deploy_timeout }}"
register: rds
when: rds_create_new_instance
tags: [db, rds]
On Fri, Jun 3, 2016 at 2:21 PM, einarc <[email protected]> wrote:
> Here are two ideas:
>
> I'm about to implement this.
>
> 1.-Do fire and forget then check back when it's ready and you REALLY need
> it:
> http://docs.ansible.com/ansible/playbooks_async.html (see last example)
> http://toroid.org/ansible-parallel-dispatch
> In my case I have plenty of things to do before I need the endpoint so is
> fine for me to wait while the instance gets instantiated, asynchronously.
>
>
> 2.-If you need to do this across plays(or not) you can use the rds_facts to
> gather the facts of the instance and loop until you get the value that you
> need. Is basically the same thing you're doing.
>
>
> On Saturday, May 28, 2016 at 2:46:58 PM UTC-7, Darren S. wrote:
>>
>> OS X 10.10.5
>> Python 2.7.11
>> Ansible 2.0.2.0
>> boto 2.40.0
>> boto3 1.3.1
>> botocore 1.4.24
>>
>>
>> Using the following tasks in a play:
>>
>> - name: db | rds | create RDS instance
>> become: no
>> local_action: rds
>> args:
>> command: create
>> instance_name: "{{ rds_instance_name }}"
>> instance_type: "{{ rds_instance_class }}"
>> vpc_security_groups: "{{ rds_instance_vpc_security_groups }}"
>> multi_zone: "{{ rds_instance_multi_zone }}"
>> subnet: "{{ rds_instance_subnet_group }}"
>> db_engine: "{{ rds_instance_engine }}"
>> publicly_accessible: "{{ rds_instance_public }}"
>> db_name: "{{ mysql_app_db_name }}"
>> size: "{{ mysql_app_db_size }}"
>> username: "{{ mysql_admin_user }}"
>> password: "{{ mysql_admin_pass }}"
>> async: 600
>> poll: 60
>> register: rds
>> tags: [db, rds]
>>
>> - name: db | rds | output db info
>> debug:
>> msg: "The new MySQL DB endpoint is {{ rds.instance.endpoint }}"
>> #var: rds
>> tags: [db, rds]
>>
>>
>> The result is that data in rds.instance is not populated completely at
>> the time the module returns successfully (changed status in this
>> case). Importantly, the 'endpoint' value is not missing. In the AWS
>> RDS console, it can be seen that the RDS instance is continuing to be
>> deployed (in "modifying" status for several minutes) and has not
>> populated a number of attributes. This is the result in Ansible when
>> it returns "early":
>>
>>
>> TASK [app : db | rds | create RDS instance]
>> **********************************
>> changed: [example.com -> localhost]
>>
>>
>> TASK [app : db | rds | output db info]
>> ****************************************
>> ok: [example.com] => {
>> "msg": "The new MySQL DB endpoint is "
>> }
>>
>> Though above, the debug 'msg' attribute shows in this case that
>> rd.instance.endpoint is empty, on a previous run I dumped the rds
>> variable and it shows many fields unpopulated:
>>
>>
>> TASK [app : db | rds | output db info]
>> ****************************************
>> ok: [example.com] => {
>> "rds": {
>> "ansible_job_id": "34553352208.25036",
>> "changed": false,
>> "finished": 1,
>> "instance": {
>> "availability_zone": "us-west-2b",
>> "backup_retention": 1,
>> "create_time": 1464425508.477,
>> "endpoint": null,
>> "id": "database",
>> "instance_type": "db.m4.large",
>> "iops": null,
>> "maintenance_window": "sun:10:23-sun:10:53",
>> "multi_zone": false,
>> "port": null,
>> "replication_source": null,
>> "status": "modifying",
>> "username": "mysqladmin",
>> "vpc_security_groups": "sg-4f02f029"
>> }
>> }
>> }
>>
>>
>> In the examples [1] for the Ansible rds module, the task uses
>> wait/wait_timeout before returning and shows that the registered
>> variable has a full set of fields. I assumed that since the RDS
>> instance creation can take a great deal of time on AWS side, it may be
>> better to use asynchronous calls to avoid any long waits/timeouts.
>> Should this work properly using async/poll? Any reason why the module
>> returns but is not able to supply a complete instance dictionary? Is
>> there a better approach for this case?
>>
>> [1] http://docs.ansible.com/ansible/rds_module.html
>>
>> Regards,
>>
>> --
>> Darren Spruell
>> [email protected]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/51f212ac-d383-49a9-bcc2-4bbf8901a5a4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Darren Spruell
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAKVSOJU3Vw-wcj1JbXGMFp9yR6XraNWbVSmyZD93aNKmhT%2BX0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
