" Basically, I'm trying to use their deployment role as a whole, to perform certain operations only on certain hosts, while leaving all the hosts/groups, listed in the the main 'hosts' directive."
This is there too :) ansible-playbook foo.yml --limit groupname ansible-playbook foo.yml --limit hostname "To nail it down, I am deploying on 10 nodes and each is having a custom connection string to its own Redis node. That would be handled via the /private folder, but I can't see a built-in way for their deployment role to do this." This doesn't seem related. I'd just do host_vars/<hostname> for this, and that's a different concept, but does not interfere with --limit. On Thu, Aug 14, 2014 at 8:27 AM, Dan Vaida <[email protected]> wrote: > That's right. But I was referring to another thing. > > Basically, I'm trying to use their deployment role as a whole, to perform > certain operations only on certain hosts, while leaving all the > hosts/groups, listed in the the main 'hosts' directive. > > In my other roles, I've been using host_vars or even defined the host vars > in the 'hosts' file and used those vars as flags for acting or not on some > particular tasks. > > To nail it down, I am deploying on 10 nodes and each is having a custom > connection string to its own Redis node. That would be handled via the > /private folder, but I can't see a built-in way for their deployment role > to do this. > > Perhaps I'm not looking at it from the right angle. > > > On Thursday, 14 August 2014 14:00:30 UTC+2, Michael DeHaan wrote: > >> "With capistrano, it is possible to run some of the tasks only on >> specific hosts. Any plans for such a feature?" >> >> This has been a feature in Ansible since day 1. >> >> - hosts: hostnames >> - hosts: otherhostnames >> >> Etc >> >> >> >> >> On Thu, Aug 14, 2014 at 7:42 AM, Dan Vaida <[email protected]> wrote: >> >>> Hello, >>> >>> Again, a very BIG thank you for your efforts on the deploy module. >>> >>> I would like to share my suggestion, perhaps as an idea to generate a >>> future pull request: >>> With capistrano, it is possible to run some of the tasks only on >>> specific hosts. Any plans for such a feature? >>> Problem is that in the /shared folder, I have stuff that's being shared >>> between releases but ALSO some mounted nfs shares. I think I will create >>> another directory in deployment root called /mounts for the NFS purposes, >>> to avoid confusion and workarounds. >>> Regardless, I think the host filter feature would come in handy. >>> >>> P.S. for us, it's important to have a simple rollback functionality so >>> you might see a fork/pr soon. >>> >>> >>> On Wednesday, 6 August 2014 15:05:14 UTC+2, Jasper N. Brouwer wrote: >>> >>>> Hi all! >>>> >>>> A little introduction for context: I'm a college/employee of Ramon de >>>> la Fuente, and we both maintain the f500.* roles in Galaxy. So when I refer >>>> to "our module", that's the same module as the one Ramon refers to. >>>> >>>> I'd like to sum up my thoughts on the discussion so far: >>>> >>>> >>>> - We choose to use the same directory layout as Capistrano does: >>>> >>>> /opt/base/current -> /opt/base/releases/{timestamp} >>>> /opt/base/releases/ >>>> /opt/base/shared/ >>>> >>>> "shared" is used for stuff that needs to survive a deploy (uploads, >>>> etc). >>>> >>>> The main reason we chose this is because it will be familiar to people >>>> who have used Capistrano. Plus we didn't see anything wrong with this >>>> layout, it suits our needs perfectly. >>>> >>>> We could make the exact file/directory names configurable though. >>>> >>>> >>>> - I agree we need something to create a consistent timestamp (or >>>> whatever) to be used on all hosts. >>>> >>>> And this probably doesn't have to be a timestamp. The reason we choose >>>> a timestamp is because it helps determine which releases should be cleaned >>>> up. We can simple order them and keep the latest X. >>>> >>>> I suspect it should be possible to stat those directories for a >>>> creation-date, and use them for the cleanup. The directory name itself can >>>> then be whatever you like (unix timestamp, yyyymmddhhmmss style timestamp, >>>> commit hash, uuid, etc). >>>> >>>> >>>> - Our current role also sets some facts, which are really convenient to >>>> have around: >>>> >>>> base_path: <must be provided through a required option> >>>> current_symlink: <base_path>/current >>>> releases_path: <base_path>/releases >>>> shared_path: <base_path>/shared >>>> current_release: <the release-timestamp/whatever that >>>> current_symlink points to> >>>> current_release_path: <base_path>/releases/<current_release> >>>> new_release: <the given/generated release-timestamp/whatever> >>>> new_release_path: <base_path>/releases/<new_release> >>>> unfinished_file: BUILD_UNFINISHED >>>> >>>> I'd like the core module to have these as well. Any thoughts on >>>> additions or changes are more than welkom! >>>> >>>> >>>> - The cleanup process we use is 2-fold: First we remove any releases >>>> that still contain the BUILD_UNFINISHED file. Next we remove any releases >>>> that exceed a configurable amount (keep 5 releases for example). >>>> >>>> This 2-fold process is very important to us, because we don't want to >>>> accidentally fail 5 releases in a row and have the cleanup process remove >>>> any older releases, therefor be left with only broken releases. The >>>> releases that are kept must be successful ones. >>>> >>>> And, we don't have this yet, but I think the cleanup should never >>>> remove the active release (the one the symlink points to), even if it's >>>> considered old). So it has to safeguard that. >>>> >>>> >>>> -- >>>> Jasper N. Brouwer >>>> (@jaspernbrouwer) >>>> >>>> >>>> On 5 August 2014 at 18:29:00, Michael DeHaan ([email protected]) >>>> wrote: >>>> > Yeah, good point, and may not be an issue anywhere really because of >>>> the >>>> > symlink, if there's good enough cleanup options. >>>> > >>>> > Not requiring that seems like it would be a nice shortcut, provided >>>> that >>>> > the module could be called to register what the "latest" was if you >>>> didn't >>>> > pass too many arguments. >>>> > >>>> > ... >>>> > >>>> > I think it would only assume a timestamp dir in base, but it could >>>> default >>>> > to make a subdir called "releases", sure. >>>> > >>>> > I think as long as we document what it does we could make up a >>>> convention, >>>> > because it's going to change the way you deploy your app a little >>>> bit, and >>>> > you would not have to use unless you wanted... >>>> > >>>> > ... >>>> > >>>> > This sounds pretty cool to me. >>>> > >>>> > ... >>>> > >>>> > I think maybe you might need to pass a parameter to remove the other >>>> ones, >>>> > and it could be optional. >>>> > >>>> > ... >>>> > >>>> > Yeah something like what you have, if not exactly, as a module seems >>>> really >>>> > really cool to me. >>>> >>>> >>>> -- >>> 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/c2b8e4c7-e5a5-4437-9508- >>> bc9717d5e1a5%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/c2b8e4c7-e5a5-4437-9508-bc9717d5e1a5%40googlegroups.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/6020a5d1-7e19-4e90-859b-8c28136648d3%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/6020a5d1-7e19-4e90-859b-8c28136648d3%40googlegroups.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/CA%2BnsWgw5Phe91RtvoVv86qCEY-fsqwfLHTOJiHPzVes1d4u%3D%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
