"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/CA%2BnsWgxG6APg2TjQyDU5i_xeEds2kkW2UtMiFDFN4ax_jyPvmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
