Just wanted to note that this code has now been merged into ec2_asg in Ansible 1.8 devel branch, and the docs are updated with examples.
Thanks, James On Mon, Sep 8, 2014 at 1:21 PM, Michael DeHaan <[email protected]> wrote: > > > On Sun, Sep 7, 2014 at 5:48 PM, James Martin <[email protected]> wrote: > >> 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? >> > > I'm not sure option 1 is transparent more so than more manual/explicit? > I guess if you mean "less abstracted", yes. I would prefer the one that > lets me forget more about how it works :) > > >> 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. >> > > Ok, so I'm thinking *MAYBE* in the examples, we show a call to ec2_lc to > show the launch config change prior to the invocation, so the user can see > this in context. > > Sidenote to all - our ec2 user guide in the docs are lacking, and I'm open > to having them mostly rewritten. Showing a more end to end tutorial, maybe > one ec2 simple one and another using ec2_lc/asg, would be really awesome > IMHO. > > >> 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/CA%2BnsWgxBOkPpMDPRjeV98CcpCc5W4F14a1RJ5aNTLcOYnCJO9w%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxBOkPpMDPRjeV98CcpCc5W4F14a1RJ5aNTLcOYnCJO9w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CAF%3D2pTZ1KmVSmmLqejpjELH0Y3ANOqbFDJ5qJ8afem04%2BfDpZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
