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