Just wanted to express my thanks for Ramon's and his colleague's work and of course Michael's on this one.
We've been successfully using this module since it first got published (3+ months) to do fairly complex deploys (dropped Capistrano in favor of this). Because of the initial version had some limitations, we've had to apply some customizations of our own, but not quite like Ramon's PR. Will go and see if we can replace our work with your PR and come back with possible suggestions :) On Thursday, 20 November 2014 00:11:35 UTC+1, Ramon de la Fuente wrote: > > I have updated the module to contain more documentation. There where a bit > more formatting options in the “Examples” section so most of the text was > moved there. > Let me know if this is more along the lines of what you had in mind. > > https://github.com/ansible/ansible-modules-extras/pull/110 > > -- > Ramon de la Fuente > Future500 B.V. > @f_u_e_n_t_e > > Goudstraat 99a, 2718RD ZOETERMEER > tel: +31 (0) 85 8773879 > web: future500.nl > > On 17 Nov 2014 at 23:28:11, Michael DeHaan (mic...@ansible.com > <javascript:>) wrote: > > Thanks! > > As for tests, definitely not - integration tests submitted with modules > are great to have. > > > > On Mon, Nov 17, 2014 at 4:38 PM, Ramon de la Fuente <ra...@future500.nl > <javascript:>> wrote: > >> All clear. It was a bit presumptuous to make a guide but I felt the >> amount of explanation needed for the module’s concepts where out of place >> in the module itself (not being actual parameters or examples). I’ll >> reformat and remove the guide. >> >> Would the tests also fall under the strange precedent category? >> >> >> -- >> Ramon de la Fuente >> Future500 B.V. >> @f_u_e_n_t_e >> >> Goudstraat 99a, 2718RD ZOETERMEER >> tel: +31 (0) 85 8773879 >> web: future500.nl >> >> On 17 Nov 2014 at 21:48:12, Michael DeHaan (mic...@ansible.com >> <javascript:>) wrote: >> >> Thanks for this! >> >> My first thought is try to clean up the examples section so there's no >> "..." ... make something real world in there, and seperate it out by use >> case. >> >> I would not like to see a seperate guide for this module as it sets a bit >> of a strange precedent, so it would be better to just show a basic set of >> playbooks in the examples. >> >> We can take a look further at implementation/usage once those get fleshed >> out a bit, so we can tell how to run them. >> >> Thanks! >> >> >> >> >> On Sun, Nov 16, 2014 at 5:55 PM, Ramon de la Fuente <ra...@future500.nl >> <javascript:>> wrote: >> >>> Ok, Michael, and everyone else of course, >>> >>> I’ve proposed the new module in a pull-request. >>> >>> The module can be found here: >>> https://github.com/ansible/ansible-modules-extras/pull/110 >>> >>> The documentation (I chose to make an additional guide in the manual): >>> https://github.com/ansible/ansible/pull/9566 >>> >>> And optionally, tests for the module: >>> https://github.com/ansible/ansible/pull/9567 >>> >>> I split the manual and the tests up into separate pull requests, >>> because I’m not sure if you guys want them or not… >>> >>> I hope you like it, let me know what you think. >>> >>> >>> -- >>> Ramon de la Fuente >>> Future500 B.V. >>> @f_u_e_n_t_e >>> >>> Goudstraat 99a, 2718RD ZOETERMEER >>> tel: +31 (0) 85 8773879 >>> web: future500.nl >>> >>> On 4 Nov 2014 at 21:48:40, Michael DeHaan (mic...@ansible.com >>> <javascript:>) wrote: >>> >>> I see yeah, the symlink for the shared folder could be part of the >>> module, but could be outside it too. >>> >>> I'm fine with it being there if that's an example. >>> >>> >>> >>> On Mon, Nov 3, 2014 at 4:25 PM, Ramon de la Fuente <ra...@future500.nl >>> <javascript:>> wrote: >>> >>>> Hey Michael, >>>> >>>> Quick reply regarding the “shared folder” >>>> >>>> With most projects there’s some form of state kept between releases. >>>> With web projects this usually means server-side session files, but >>>> possibly also user-generated content like uploaded files and such. All our >>>> projects have at least one shared folder. >>>> >>>> root/releases/1/sessions -> root/shared/sessions >>>> root/releases/1/uploads -> root/shared/uploads >>>> >>>> root/releases/2/sessions -> root/shared/sessions >>>> root/releases/2/uploads -> root/shared/uploads >>>> >>>> Our deploy role takes care of creating and linking to the >>>> subfolders of /shared, but creation of the shared folder itself *could* be >>>> part of the role. Not really that big of a deal though, it saves just one >>>> task - and maybe adds some confusion as to what it is and what it should >>>> do. >>>> >>>> Kind regards, >>>> >>>> >>>> Ramon >>>> >>>> >>>> On 3 Nov 2014 at 15:23:23, Michael DeHaan (mic...@ansible.com >>>> <javascript:>) wrote: >>>> >>>> >>>> >>>>> >>>>> When we take a “deploy_helper" module into account, it could look like >>>>> this: >>>>> >>>>> 1. deploy state=present path=/path/to/root >>>>> - creates project root folder >>>>> - returns a timestamp >>>>> - creates the releases folder >>>>> - creates the shared folder (optional) >>>>> ~~~ clone, build, prepare ~~~ (outside of the scope of the module) >>>>> 1. deploy state=finalize >>>>> - removes build in progress file >>>>> - creates a symlink >>>>> - optionally does cleanup >>>>> ----------------------------------------- >>>>> This could be done in 2 tasks (+1 if we exclude the ‘shared' folder >>>>> creation from the module) >>>>> >>>> >>>> >>>> This looks really good to me. >>>> >>>> I much prefer the idea of a mostly self-contained module as it makes >>>> the amount of work everyone has to do to use the above much more condensed. >>>> >>>> If 2000 people use it, we might have saved the world 20,000 minutes or >>>> more, etc :) >>>> >>>> >>>> >>>>> >>>>> Looking at the options required, the module might take on this >>>>> signature: >>>>> >>>>> deploy_helper parameters: >>>>> required: >>>>> path= /path/to/project-root >>>>> >>>>> not required: >>>>> release= (default: timestamp) >>>>> owner= (default: null) >>>>> group= (default: null) >>>>> mode= (default: null) >>>>> keep_releases= (default: 5) >>>>> create_shared_folder= (default: true) >>>>> releases_path= (default: {{ path }}/releases) >>>>> shared_path= (default: {{ path }}/shared) >>>>> current_path= (default: {{ path }}/current) >>>>> unfinished_filename= (default: DEPLOY_UNFINISHED) >>>>> >>>> >>>> >> I may be a little unclear on what the "shared path" is. Can you >>>> remind me? >>>> >>>> >>>> >>>>> state=[ present, absent, clean, finalize, query ] (default: >>>>> present) >>>>> >>>>> >>>>> Besides your general opinion, I was pondering the following practical >>>>> questions: >>>>> >>>>> 1: What category of module would this module be under? File? >>>>> >>>> >>>> >> "web infrastructure" seems ideal for now. We may decide to >>>> reorganize the categories in the near future. >>>> >>>> >>>>> 2: Should the (optional) creation of a shared folder be part of a >>>>> deploy module? >>>>> >>>> >>>> >> see my question above as I'm not quite remembering what a shared >>>> folder is right now :) >>>> >>>> >>>>> 3: Should we even be duplicating code like creation of the symlink? >>>>> The file module already does that... >>>>> >>>> >>>> >> There should be common code for this in module_utils. If not, we >>>> can move the file code there and make it use that, >>>> to avoid duplication. >>>> >>>> I do believe it's important to represent the "idea" (atomic deploys >>>> with timestamps) versus the "how", and saving as many steps as possible. >>>> >>>> >>>>> >>>>> Thanks for any feedback, kind regards, >>>>> >>>>> >>>> Thanks a ton for building this! >>>> >>>> >>>> >>>>> Ramon >>>>> @f_u_e_n_t_e >>>>> >>>>> >>>>> Op donderdag 30 oktober 2014 18:17:28 UTC+1 schreef Michael DeHaan: >>>>>> >>>>>> 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, <ra...@future500.nl> 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 <vaid...@gmail.com> >>>>>>>> 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 <vaid...@gmail.com> >>>>>>>>>> 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 ( >>>>>>>>>>>> mic...@ansible.com) 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 ansible-proje...@googlegroups.com. >>>>>>>>>>> To post to this group, send email to ansible...@googlegroups.com >>>>>>>>>>> . >>>>>>>>>>> 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 ansible-proje...@googlegroups.com. >>>>>>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>>>>>> 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 ansible-proje...@googlegroups.com. >>>>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>>>> 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 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/d7e4efab-9bac-4204-a5cb-c32a9902d395%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/ansible-project/d7e4efab-9bac-4204-a5cb-c32a9902d395%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 a topic in the >>>> Google Groups "Ansible Project" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/ansible-project/R3Kr2uMYUt4/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, 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/CA%2BnsWgzRvoLQ_H%3DPV4yFkaNWdDdROhXY-KxKoDUwMEK3XuDLmQ%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzRvoLQ_H%3DPV4yFkaNWdDdROhXY-KxKoDUwMEK3XuDLmQ%40mail.gmail.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 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/etPan.5457f2df.6b8b4567.c680%40FzzBook.fritz.box >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/etPan.5457f2df.6b8b4567.c680%40FzzBook.fritz.box?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 a topic in the >>> Google Groups "Ansible Project" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/ansible-project/R3Kr2uMYUt4/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, 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/CA%2BnsWgxPaNi5Gjz_qHmnihKk8CVtRqrJg-2SXOfUZAkktJCT6g%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPaNi5Gjz_qHmnihKk8CVtRqrJg-2SXOfUZAkktJCT6g%40mail.gmail.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 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/22b30aac-1b90-45ed-bed7-2d2bd654e733%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
