Nice, very much looking forward to this. If you have a PR ready maybe reply to the list so you can make sure to get our attention on it.
Thanks!!! On Sat, Oct 25, 2014 at 5:02 PM, <[email protected]> wrote: > Hey All, > > Sorry about the radio silence on this thread, I kind of dropped the ball > on this one :-( > > I'm picking up where I left off, I'll work out the options for the module > to move this thing forward. I think my last ideas revolved around two > options for the module, one where we have a (semi) fixed folder structure - > and one where we're only interested in the symlink and cleanup. > > If anyone has had thoughts about it since august, feel free to add them - > I'll be working on this next week. > > Kind regards, > > > Ramon > > > Op donderdag 14 augustus 2014 14:34:10 UTC+2 schreef Michael DeHaan: >> >> " >> 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/0b5ecc2c-befc-459c-a260-fc4e6b09f4c9%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/0b5ecc2c-befc-459c-a260-fc4e6b09f4c9%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%2BnsWgw%3D-c3Lx80iSciuu%2BkX%3DA%3DcmsYMh%3DgeKYJ_JKD79Ax%2B8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
