Sometimes when using digital_ocean with wait=no I get the error "No ip is found". But with wait=no I wouldn't expect there to be any IP, that gets allocated later. However, looking at the code, it turns out that with even with wait=no it waits up to 10 seconds for an IP to be allocated. We could wait longer, but with wait=no that seems like the wrong choice; it's easy enough to grab an IP later with a wait=yes command. To make this change I removed the call to update_attr in @classmethod add. An add is always followed by an ensure_powered_on which will do the update_attr if wait=yes. It would be possible to instead do a call to update_attr with no retries and ignore the errors but I figured it would be better to be consistently not return an IP than to sometimes return it and sometimes not. Inconsistent behaviour makes debugging deployment scripts very difficult.
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cloudformation | Loading commit data... | |
| digital_ocean | Loading commit data... | |
| ec2 | Loading commit data... | |
| ec2_elb | Loading commit data... | |
| ec2_facts | Loading commit data... | |
| ec2_vol | Loading commit data... | |
| glance_image | Loading commit data... | |
| keystone_user | Loading commit data... | |
| linode | Loading commit data... | |
| nova_compute | Loading commit data... | |
| nova_keypair | Loading commit data... | |
| quantum_floating_ip | Loading commit data... | |
| quantum_floating_ip_associate | Loading commit data... | |
| quantum_network | Loading commit data... | |
| quantum_router | Loading commit data... | |
| quantum_router_gateway | Loading commit data... | |
| quantum_router_interface | Loading commit data... | |
| quantum_subnet | Loading commit data... | |
| rax | Loading commit data... | |
| rds | Loading commit data... | |
| s3 | Loading commit data... | |
| virt | Loading commit data... |