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. For more options, visit https://groups.google.com/d/optout.
