No plans for this at this time. I understand the appealing nature of this one, I think it might make sense as a non-core connection plugin perhaps.
But the usage of FreeBSD jails is small now, and I don't think we'd want to continue to maintain this as sort of a "cloud starter kit". Hope that makes sense. On Tue, Sep 16, 2014 at 4:54 AM, Paul Körbitz <paul.koerb...@gmail.com> wrote: > Hi all, > > > Yes, it is. I've started hacking on it (see https://github.com/ktosiek/ > ansible-nested-connections. It only supports chroot, but jail shouldn't > be hard to add), and I've stumbled upon some problems: > > I was wondering what the status was on this one? I also need the > *configure jails on ssh-accessible jailhost* functionality. If there is no > further development I might try to add support for jails for this. > > Cheers > Paul > > > > On Tuesday, August 12, 2014 8:05:43 PM UTC+2, Tomasz Kontusz wrote: >> >> On 09.08.2014 01:23, Michael DeHaan wrote: >> >> >> >> "I don't think ssh.py (or any other specific connection plugin) is a >> good place for this, I think it should rather be done as separate plugin or >> in core. >> >> That's because I'd like to see the same layers used with >> local/ssh/accelerate." >> >> >> I'm not sure that's a good idea. >> >> >> (A) all distros are moving to new enough SSH that paramiko is going to >> be less important, and with no paramiko there will be no need for accelerate >> >> (B) the concept of "nesting" here is probably going to be way more >> difficult than just doing it for one plugin. >> >> Yes, it is. I've started hacking on it (see https://github.com/ktosiek/ >> ansible-nested-connections. It only supports chroot, but jail shouldn't >> be hard to add), and I've stumbled upon some problems: >> * to have a sudo layer as robust as sudo functionality in SSH, layers >> would need some way to get partial output from commands. >> I'm thinking about using generators or something similar, but >> considering that "yield from" and mixing yield with return were only added >> somewhere in py3, it might turn out pretty ugly. >> * put/fetch might need some more freedom than just changing the path on >> managed host, but that shouldn't be hard to add (except maybe for risking a >> loop between exec_command and put/fetch). >> >> (C) yes, the local case would require ssh, but this seems less >> important in the long run. >> >> >> >> >> >> >> >> On Thu, Aug 7, 2014 at 5:52 PM, Tomasz Kontusz <tomasz....@gmail.com> >> wrote: >> >> >>> >>> >>> >>> >>> On 07.08.2014 23:35, Michael DeHaan >>> wrote: >>> >>> >>> >>> >>> "I'm putting it in ansible_ssh_host like >>> this: >>> >>> some_container ansible_connection=vzenter >>> ansible_ssh_host=<SSH host>|<CTID>" >>> >>> >>> >>> Maybe like this: >>> >>> >>> >>> >>> ansible_ssh_host=hostname;container=CTID >>> >>> >>> >>> I like that syntax, thanks. I'm thinking about doing something like: >>> >>> ansible_connection=stack ansible_ssh_host=<connection >>> plugin>=<hostname for that plugin>;<connection >>> layer>=<"hostname" for that layer> >>> >>> >>> >>> >>> >>> >>> If that could be implemented natively in Ansible's SSH.py, >>> without doing too much damage, I would be SUPER interested. >>> >>> >>> >>> I don't think ssh.py (or any other specific connection plugin) is a >>> good place for this, I think it should rather be done as separate >>> plugin or in core. >>> >>> That's because I'd like to see the same layers used with >>> local/ssh/accelerate. >>> >>> >>> >>> >>> >>> >>> I'd like to see something somewhat pluggable, and in order >>> to take it, it would need to support Docker initially. >>> >>> >>> >>> Right, as Ansible already has a plugin system I think that should be >>> doable :-) >>> >>> And being pluggable is a big part of it for me - I don't want to >>> have separate plugin for each base plugin/layer combination. >>> >>> >>> >>> >>> >>> >>> Though I do feel the "no SSH in containers" statement is a >>> little religious. They want to encourage automation, but when >>> the automation uses SSH, that's totally cool :) >>> >>> >>> >>> For me it was either jump hosts or entering containers, and the >>> latter seemed more robust (I can access containers with broken >>> networking :-)) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Aug 7, 2014 at 3:57 PM, Tomasz Kontusz <tomasz....@gmail.com> >>> wrote: >>> >>> >>>> >>>> On 07.08.2014 17:47, Alberto Berti wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> sorry for the confusing precendence of my latter >>>>> message, but seems that >>>>> >>>>> this message had some problems with gmane, so i'm >>>>> resending it.... >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> "Tomasz" == Tomasz Kontusz <tomasz....@gmail.com> >>>>>>>>>> writes: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> Tomasz> On 04.08.2014 12:14, Filias Heidt >>>>> wrote: >>>>> >>>>> >> I thought the more generic "nesting" >>>>> would be a good thing, because >>>>> >>>>> >> the next guy might want to control >>>>> Docker instances or Containers on >>>>> >>>>> >> a remote host without them having a >>>>> public IP. Maybe I'll try to >>>>> >>>>> >> write a connection plugin. >>>>> >>>>> Tomasz> The way connection plugins work, it's >>>>> not going to be possible to nest >>>>> >>>>> Tomasz> existing ones. >>>>> >>>>> Tomasz> But what you can do is, create a new >>>>> API for "connection plugin >>>>> >>>>> Tomasz> layers" that can be put on top of an >>>>> existing "base" connection >>>>> >>>>> Tomasz> plugin. >>>>> >>>>> Tomasz> Something like: >>>>> >>>>> >>>>> >>>>> Tomasz> class ConnectionLayer(object): >>>>> >>>>> Tomasz> def __init__(self, >>>>> target_address): >>>>> >>>>> Tomasz> """target_address is a part of >>>>> ansible_ssh_host for this >>>>> >>>>> Tomasz> plugin, like jail's path""" >>>>> >>>>> >>>>> >>>>> Tomasz> def wrap_command(self, command): >>>>> >>>>> Tomasz> """Wraps the command in >>>>> chroot/jail/etc.""" >>>>> >>>>> >>>>> >>>>> Tomasz> def unwrap_result(self, rc, >>>>> stdout, stderr): >>>>> >>>>> Tomasz> """Takes whatever the wrapped >>>>> command returned after being run >>>>> >>>>> Tomasz> by the base connection plugin, >>>>> >>>>> Tomasz> and returns a new tuple of >>>>> (rc, stdout, stderr)""" >>>>> >>>>> >>>>> >>>>> Tomasz> def wrap_path(self, path): >>>>> >>>>> Tomasz> """Takes a path inside >>>>> container/chroot/jail and translates it >>>>> >>>>> Tomasz> into host path.""" >>>>> >>>>> >>>>> >>>>> any update on this? I would like to use nsenter [1]_ >>>>> to run commands >>>>> >>>>> inside the container (how to transfer files is a >>>>> detail i have yet to >>>>> >>>>> analyze) to work on docker containers either locally >>>>> or on a remote >>>>> >>>>> host, and i would really like to contribute to and use >>>>> a layer like >>>>> >>>>> this. Unfortunately i'm quite new to ansible and not >>>>> all the details >>>>> >>>>> involving connections are clear to me. >>>>> >>>>> >>>> >>>> >>>> I'll see what I can do, but I wouldn't hold my breath about >>>> opening the one I wrote at work. >>>> >>>> And hey, it's always a good time to rewrite something :-) >>>> >>>> >>>> >>>> >>>> >>>>> Tomasz> I would actually like to see >>>>> something like this, as I've written a >>>>> >>>>> Tomasz> OpenVZ-over-SSH connection plugin at >>>>> work (and I can already give you >>>>> >>>>> Tomasz> a hint: don't try to put host address >>>>> anywhere but ansible_ssh_host, >>>>> >>>>> Tomasz> this variable gets special treatment. >>>>> I've tried to have separate >>>>> >>>>> Tomasz> ansible_vzenter_ctid, and in the end had >>>>> to rewrite that part). >>>>> >>>>> >>>>> >>>>> Nice! openvz is the other virtualization system i use >>>>> :-) >>>>> >>>>> >>>>> >>>>> So, where you store the ctid? in to so other host >>>>> related variable? Can >>>>> >>>>> you say more about having something like a variable >>>>> ansible_vzenter_ctid >>>>> >>>>> is not feasible? >>>>> >>>>> >>>> >>>> I'm putting it in ansible_ssh_host like this: >>>> >>>> some_container ansible_connection=vzenter >>>> ansible_ssh_host=<SSH host>|<CTID> >>>> >>>> >>>> >>>> Using variable other than ansible_ssh_host is not feasible, >>>> as they are not provided to connection plugins. >>>> >>>> You can extract them from runner (as connection plugins do >>>> get access to runner), but you can't support the >>>> delegate_to: '{{ item }}' pattern this way (as you don't get >>>> access to loop items). >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Alberto >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> 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/53E3DA41.7050904%40gmail.com. >>>> >>>> >>>> >>>> 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/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgv >>> Kw6cffGAUtAWiScbZiuw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgvKw6cffGAUtAWiScbZiuw%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. >>> >>> 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/53E3F519.2030501%40gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/53E3F519.2030501%40gmail.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/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hW >> gtuzS_SajAS9q%3Dz0rwhA%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hWgtuzS_SajAS9q%3Dz0rwhA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> are running > I was wondering what the status was on this one? I also need the > *configure jails on ssh-accessible jailhost* functionality (I'm a bit > surprised this is not considered a common use case TBH). > > > > On Tuesday, August 12, 2014 8:05:43 PM UTC+2, Tomasz Kontusz wrote: >> >> On 09.08.2014 01:23, Michael DeHaan wrote: >> >> >> >> "I don't think ssh.py (or any other specific connection plugin) is a >> good place for this, I think it should rather be done as separate plugin or >> in core. >> >> That's because I'd like to see the same layers used with >> local/ssh/accelerate." >> >> >> I'm not sure that's a good idea. >> >> >> (A) all distros are moving to new enough SSH that paramiko is going to >> be less important, and with no paramiko there will be no need for accelerate >> >> (B) the concept of "nesting" here is probably going to be way more >> difficult than just doing it for one plugin. >> >> Yes, it is. I've started hacking on it (see https://github.com/ktosiek/ >> ansible-nested-connections. It only supports chroot, but jail shouldn't >> be hard to add), and I've stumbled upon some problems: >> * to have a sudo layer as robust as sudo functionality in SSH, layers >> would need some way to get partial output from commands. >> I'm thinking about using generators or something similar, but >> considering that "yield from" and mixing yield with return were only added >> somewhere in py3, it might turn out pretty ugly. >> * put/fetch might need some more freedom than just changing the path on >> managed host, but that shouldn't be hard to add (except maybe for risking a >> loop between exec_command and put/fetch). >> >> (C) yes, the local case would require ssh, but this seems less >> important in the long run. >> >> >> >> >> >> >> >> On Thu, Aug 7, 2014 at 5:52 PM, Tomasz Kontusz <tomasz....@gmail.com> >> wrote: >> >> >>> >>> >>> >>> >>> On 07.08.2014 23:35, Michael DeHaan >>> wrote: >>> >>> >>> >>> >>> "I'm putting it in ansible_ssh_host like >>> this: >>> >>> some_container ansible_connection=vzenter >>> ansible_ssh_host=<SSH host>|<CTID>" >>> >>> >>> >>> Maybe like this: >>> >>> >>> >>> >>> ansible_ssh_host=hostname;container=CTID >>> >>> >>> >>> I like that syntax, thanks. I'm thinking about doing something like: >>> >>> ansible_connection=stack ansible_ssh_host=<connection >>> plugin>=<hostname for that plugin>;<connection >>> layer>=<"hostname" for that layer> >>> >>> >>> >>> >>> >>> >>> If that could be implemented natively in Ansible's SSH.py, >>> without doing too much damage, I would be SUPER interested. >>> >>> >>> >>> I don't think ssh.py (or any other specific connection plugin) is a >>> good place for this, I think it should rather be done as separate >>> plugin or in core. >>> >>> That's because I'd like to see the same layers used with >>> local/ssh/accelerate. >>> >>> >>> >>> >>> >>> >>> I'd like to see something somewhat pluggable, and in order >>> to take it, it would need to support Docker initially. >>> >>> >>> >>> Right, as Ansible already has a plugin system I think that should be >>> doable :-) >>> >>> And being pluggable is a big part of it for me - I don't want to >>> have separate plugin for each base plugin/layer combination. >>> >>> >>> >>> >>> >>> >>> Though I do feel the "no SSH in containers" statement is a >>> little religious. They want to encourage automation, but when >>> the automation uses SSH, that's totally cool :) >>> >>> >>> >>> For me it was either jump hosts or entering containers, and the >>> latter seemed more robust (I can access containers with broken >>> networking :-)) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Aug 7, 2014 at 3:57 PM, Tomasz Kontusz <tomasz....@gmail.com> >>> wrote: >>> >>> >>>> >>>> On 07.08.2014 17:47, Alberto Berti wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> sorry for the confusing precendence of my latter >>>>> message, but seems that >>>>> >>>>> this message had some problems with gmane, so i'm >>>>> resending it.... >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> "Tomasz" == Tomasz Kontusz <tomasz....@gmail.com> >>>>>>>>>> writes: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> Tomasz> On 04.08.2014 12:14, Filias Heidt >>>>> wrote: >>>>> >>>>> >> I thought the more generic "nesting" >>>>> would be a good thing, because >>>>> >>>>> >> the next guy might want to control >>>>> Docker instances or Containers on >>>>> >>>>> >> a remote host without them having a >>>>> public IP. Maybe I'll try to >>>>> >>>>> >> write a connection plugin. >>>>> >>>>> Tomasz> The way connection plugins work, it's >>>>> not going to be possible to nest >>>>> >>>>> Tomasz> existing ones. >>>>> >>>>> Tomasz> But what you can do is, create a new >>>>> API for "connection plugin >>>>> >>>>> Tomasz> layers" that can be put on top of an >>>>> existing "base" connection >>>>> >>>>> Tomasz> plugin. >>>>> >>>>> Tomasz> Something like: >>>>> >>>>> >>>>> >>>>> Tomasz> class ConnectionLayer(object): >>>>> >>>>> Tomasz> def __init__(self, >>>>> target_address): >>>>> >>>>> Tomasz> """target_address is a part of >>>>> ansible_ssh_host for this >>>>> >>>>> Tomasz> plugin, like jail's path""" >>>>> >>>>> >>>>> >>>>> Tomasz> def wrap_command(self, command): >>>>> >>>>> Tomasz> """Wraps the command in >>>>> chroot/jail/etc.""" >>>>> >>>>> >>>>> >>>>> Tomasz> def unwrap_result(self, rc, >>>>> stdout, stderr): >>>>> >>>>> Tomasz> """Takes whatever the wrapped >>>>> command returned after being run >>>>> >>>>> Tomasz> by the base connection plugin, >>>>> >>>>> Tomasz> and returns a new tuple of >>>>> (rc, stdout, stderr)""" >>>>> >>>>> >>>>> >>>>> Tomasz> def wrap_path(self, path): >>>>> >>>>> Tomasz> """Takes a path inside >>>>> container/chroot/jail and translates it >>>>> >>>>> Tomasz> into host path.""" >>>>> >>>>> >>>>> >>>>> any update on this? I would like to use nsenter [1]_ >>>>> to run commands >>>>> >>>>> inside the container (how to transfer files is a >>>>> detail i have yet to >>>>> >>>>> analyze) to work on docker containers either locally >>>>> or on a remote >>>>> >>>>> host, and i would really like to contribute to and use >>>>> a layer like >>>>> >>>>> this. Unfortunately i'm quite new to ansible and not >>>>> all the details >>>>> >>>>> involving connections are clear to me. >>>>> >>>>> >>>> >>>> >>>> I'll see what I can do, but I wouldn't hold my breath about >>>> opening the one I wrote at work. >>>> >>>> And hey, it's always a good time to rewrite something :-) >>>> >>>> >>>> >>>> >>>> >>>>> Tomasz> I would actually like to see >>>>> something like this, as I've written a >>>>> >>>>> Tomasz> OpenVZ-over-SSH connection plugin at >>>>> work (and I can already give you >>>>> >>>>> Tomasz> a hint: don't try to put host address >>>>> anywhere but ansible_ssh_host, >>>>> >>>>> Tomasz> this variable gets special treatment. >>>>> I've tried to have separate >>>>> >>>>> Tomasz> ansible_vzenter_ctid, and in the end had >>>>> to rewrite that part). >>>>> >>>>> >>>>> >>>>> Nice! openvz is the other virtualization system i use >>>>> :-) >>>>> >>>>> >>>>> >>>>> So, where you store the ctid? in to so other host >>>>> related variable? Can >>>>> >>>>> you say more about having something like a variable >>>>> ansible_vzenter_ctid >>>>> >>>>> is not feasible? >>>>> >>>>> >>>> >>>> I'm putting it in ansible_ssh_host like this: >>>> >>>> some_container ansible_connection=vzenter >>>> ansible_ssh_host=<SSH host>|<CTID> >>>> >>>> >>>> >>>> Using variable other than ansible_ssh_host is not feasible, >>>> as they are not provided to connection plugins. >>>> >>>> You can extract them from runner (as connection plugins do >>>> get access to runner), but you can't support the >>>> delegate_to: '{{ item }}' pattern this way (as you don't get >>>> access to loop items). >>>> >>>> >>>> >>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Alberto >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> 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/53E3DA41.7050904%40gmail.com. >>>> >>>> >>>> >>>> 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/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgv >>> Kw6cffGAUtAWiScbZiuw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwx54dt5OAZOyU4ZG28JeTwgvKw6cffGAUtAWiScbZiuw%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. >>> >>> 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/53E3F519.2030501%40gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/53E3F519.2030501%40gmail.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/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hW >> gtuzS_SajAS9q%3Dz0rwhA%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPYib1LYxQbvoz8daoFhB6hWgtuzS_SajAS9q%3Dz0rwhA%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/2a66d3ef-6259-4360-93d8-7931c15f1fc0%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/2a66d3ef-6259-4360-93d8-7931c15f1fc0%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-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/CA%2BnsWgzRfDLp6BqUZoj7FYmBsHu15JU8AhFeq9DBqqnkCbQ4ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
