Dear Michael,

OK, thanks for the heads up. I'll see if I get this working myself then.

cheers
P

On Tue, Sep 16, 2014 at 4:50 PM, Michael DeHaan <[email protected]> wrote:

> 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 <[email protected]>
> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>>>>>>>> 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 [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/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 [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%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 [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/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 [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%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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>>>>>>>> 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 [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/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 [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%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 [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/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 [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%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 [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/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 a topic in the
> Google Groups "Ansible Project" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ansible-project/snM7n1QGoAw/unsubscribe.
> To unsubscribe from this group and all its topics, 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%2BnsWgzRfDLp6BqUZoj7FYmBsHu15JU8AhFeq9DBqqnkCbQ4ow%40mail.gmail.com
> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzRfDLp6BqUZoj7FYmBsHu15JU8AhFeq9DBqqnkCbQ4ow%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 [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/CAGoS-TT86tv%3DWjEKFT5GHxWPmrDBbb2t%3D9t9DEE__b9OeQM2DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to