We're going to use a different means of updating our instances: 1) Update the application AMI offline 2) Change the autoscaler to use the new AMI 3) Gracefully down and kill the old AMI instances in the ELB 4) The ELB will start up new AMI instances as the old ones die 5) Profit!
-scott On Mar 9, 2014, at 11:55 PM, C. S. <[email protected]> wrote: > We've had issues with this module too (1.4.x)... > > The main issue being that it de-registeres the instance from the ELB and > doesn't store which ELB is removed it from anywhere. So if there is a failure > before the re-register, you have to manually add it back to the ELB pool (and > it breaks autoscale in the mean time). I wonder if the module should update > an EC2 tag on the instance first, so it knows how to put it back on > subsequent runs if it couldn't re-register it in a previous run. > > Our workaround was to de-register and immediately re-register the instance > with the ELB so that just the healthcheck gets reset while we update an > instance's app. Additionally we had add retries to the module, since we > occasionally will get throttled by the AWS APIs. > > Here is the algorithm that AWS recommends for their APIs: > http://docs.aws.amazon.com/general/latest/gr/api-retries.html > > On Feb 20, 2014, at 10:18 , Alexander Popov <[email protected]> wrote: > >> I observed similar issue with ec2_group and ec2_vpc (while creating subnets, >> route tables, associations, etc.) >> >> On Friday, February 14, 2014 12:35:27 PM UTC-5, Scott Anderson wrote: >> Are there other modules that behave in this fashion as well? >> >> If so a generic retry loop that takes a callable for checking state might be >> useful as a bit of refactoring. >> >> -scott >> >> On Thursday, February 13, 2014 4:26:12 PM UTC-5, Bruce Pennypacker wrote: >> while not timeout_exceeded: >> get_instance_state >> if InService: >> return success; >> else if instance_error AND timeout_exceeded: >> return error; >> sleep 1 >> >> return timeout >> >> Any comments/suggestions about this, especially from other folks using the >> ec2_elb module? >> >> -Bruce >> >> >> >> -- >> 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]. >> For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/qG9Thrx100A/unsubscribe. > To unsubscribe from this group and all its topics, 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/417B2C4B-A192-4BE2-8EDC-47AF986AABEC%40yahoo.com. > For more options, visit https://groups.google.com/d/optout. -- 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/4B57EFC7-46ED-4CD2-9F02-2D11166FABF7%40gmail.com. For more options, visit https://groups.google.com/d/optout.
