I have some relatively extensive documentation on ec2 - it might be a little too over the top for the user guide. http://willthames.github.io/2014/03/17/ansible-layered-configuration-for-aws.html
If you want me to incorporate any or all of it into the user guide, I'd be happy to do so. I haven't done enough with asgs to contribute much (and it seems like James' docs are pretty good to go anyway) Will On Tuesday, September 9, 2014 3:21:14 AM UTC+10, Michael DeHaan wrote: > > > > On Sun, Sep 7, 2014 at 5:48 PM, James Martin <jma...@ansible.com > <javascript:>> 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" <mic...@ansible.com >> <javascript:>> 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 <jma...@ansible.com >>> <javascript:>> 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 <mic...@ansible.com >>>> <javascript:>> 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 <danl...@gmail.com >>>>> <javascript:>> 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 ansible-proje...@googlegroups.com <javascript:>. >>>>>> To post to this group, send email to ansible...@googlegroups.com >>>>>> <javascript:>. >>>>>> 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/0cbd0506-887c-4dbc-9bc9-57576a5b2005%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
