Michael, The reason for having both was to spur this very discussion. :). Option 1 is a bit more complicated but more transparent, option 2 is much easier but less transparent. I'm more fond of option 2, and happy to make it the only one. BTW, are we talking about the docs or the actual feature?
As far as what the instances are being replaced with-- the ASG is going to spin up new instances with the current launch configuration. With option 2, the module starts by building a list of which instances should be replaced. This list is made up of all instances that have not been launched with the current launch configuration. The module then bumps the size of the ASG by the replace_batch size. It then terminates replace_batch_size instances at a time, waits for the ASG to spin up new instances in their place and become healthy, then continues on down the list until there are no more left to replace. Then it sets the ASG size back to it's original value. James On Sep 7, 2014 3:26 PM, "Michael DeHaan" <[email protected]> wrote: > Hi James, > > Thanks! > > In reading the PR examples section, I'm curious why we might show Option 1 > if Option 2 is much cleaner and would be interested in details. > > Also, quick question - it's replacing all instances, but what's it > replacing them *with* ? > > Perhaps this is something we should show as well, where we indicate how to > specify what the new instance IDs would be. > > Can you help me grok additions? > > Thanks again! > > +## Option 2 +This does everything that Option 1 does, but is contained > inside the module. It's more opaque,+but the playbooks end up being much > clearer.+++- ec2_asg:+ name: myasg+ health_check_period: 60+ > health_check_type: ELB+ replace_all_instances: yes+ min_size: 5+ > max_size: 5+ desired_capacity: 5+ region: us-east-1++ > > On Sun, Sep 7, 2014 at 2:49 PM, James Martin <[email protected]> wrote: > >> Dan, >> >> I've been tinkering with this process for quite a while and have made a >> pull request to ansible core that I believe does what you are looking for: >> >> https://github.com/ansible/ansible/pull/8901 >> >> As Michael stated, we will be releasing a blog post that's going to go >> more in depth in describing a few different ways to perform updates to >> ASG's that use pre-baked AMIs (this module approach being one of them). >> >> I appreciate any feedback/testing you can provide on that pull request of >> course. The documentation is inline in the module source. >> >> Thanks, >> >> >> - James >> >> >> On Sun, Sep 7, 2014 at 2:23 PM, Michael DeHaan <[email protected]> >> wrote: >> >>> Hi, >>> >>> James Martin is working on a 2-3 part blog post on *exactly* this >>> subject, which I believe we're going to be posting this week, which shows a >>> couple of ways to do it. >>> >>> I've included him on this mailing list thread if he wants to share some >>> cliff-notes. >>> >>> --Michael >>> >>> >>> >>> >>> On Sun, Sep 7, 2014 at 2:08 PM, Daniel Langer <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> I'm trying to use Ansible to do a rolling deploy against an ELB linked >>>> to an auto-scaling group (ASG), using a pre-baked AMI. My ideal process >>>> would go something like this >>>> >>>> 1. Get the current membership of the ASG >>>> 2. Update the launch configuration for the ASG >>>> 3. For each member: >>>> 3a. Create an instance using the new AMI >>>> 3b. Associate the instance with the ASG >>>> 3c. Terminate the original instance >>>> >>>> The other option I was considering was: >>>> >>>> 1. Get the current membership of the ASG >>>> 2. Update the launch configuration for the ASG >>>> 3. For each member: >>>> 3a. Terminate the instance >>>> 3b. Wait until the ASG has noticed and launched a new instance before >>>> continuing >>>> >>>> For the former, I don't see a way using the built-in EC2 modules to >>>> associate an instance with an ASG. For the latter, I'm not clear how I'd >>>> wait until the ASG has launched a new instance to catch up with the one I >>>> terminated. >>>> >>>> Any suggestions on how to do either one, or if that's not possible, >>>> what the best-practice for what I'm trying to do it? >>>> >>>> Thanks, >>>> >>>> Dan >>>> >>>> -- >>>> 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/42240c16-c2a5-4dac-b6f9-a30fc6e5b8d2%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/42240c16-c2a5-4dac-b6f9-a30fc6e5b8d2%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> >> >> -- >> James Martin >> Solutions Architect >> Ansible, Inc. >> > > -- 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/CAMP2DW7%3DfKDDn9u1mVvi8R%2B-E5RF4wAvmbAxCFkcJF247UV%2B%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
