Why doesn't ansible-pylibssh rely on the bindings provided by the ssh-python project?

[pkittenis]

Hello,

Am wondering on the motivation for creating this new project for bindings for libssh rather than using ssh-python which covers all of the libssh API up to latest version - 0.9.5.

It also provides binary wheels for manylinux, OS X and Windows (64-bit) for Python 2.7 and 3.5-3.9, as well as having automated integration tests, good test coverage and has been used in real-world applications for a few years now.

This project seems to duplicate what is provided by ssh-python for only a subset of the libssh API.

Was there something needed missing in ssh-python that is provided by this project?

Not invented here?

Disclaimer - author of said bindings.

[ganeshrn]

The Ansible use case required a subset of libssh client API's and with this goal, we had done a POC using the ssh-python library in early 2019 and had hit a couple of roadblocks for which issue/PR's were raised by @adelton can be referred here. At that time it seemed the project was not actively maintained and lacked the required traction that we were hoping for, which is the main reason why we choose to implement an opinionated and minimalistic extension library to serve the Ansible network-specific use case.

[webknjaz]

I think we're way past the point where it'd be useful to us. We have a need to have a paramiko-compatible interface because this library serves the purpose of being a drop-in replacement on the Ansible connection plugin level, in particular. A lot of effort has been spent making things work, setting up the packaging, and CI/CD. We don't have spare resources to remake everything now. Besides, I'm going to do some other packaging work involving RPMs and we need to make such builds in trusted envs.

Maybe it'll be possible in the future but right now it's not even something that the security team approved (partially because the maintenance was dead at that time, there were no tests for required bindings, nor required libssh version was supported), and auditing a new dependency would take time which I don't think we have now.

[pkittenis]

These assertions seem false.

Integration tests can be found here, far outnumbering tests in this project. CI/CD already exists, wheels already exist, examples on how to make RPMs exist (and these have existed since 2018).

Libssh version up to latest is supported, as mentioned. Last release was last month.

I would urge you and the company sponsoring this work to focus such efforts into existing projects where they were found to be missing certain requirements rather than taking on the far more expensive and time consuming task of recreating them.

Have no vested interest either way personally. Even now, there will be a lot of time and effort needed to get this project stable enough as looking at the code, it does not yet appear ready for use. Implementing integration tests would demonstrate as such.

Thank you for the information.

[webknjaz]

No, they are not false. We just have what we need right now and there are no resources to change that. Of course, we'd like to have the relevant part of this maintained upstream but this transition would need more involvement than we can afford right now. You imply that it's NIH but it's just not true at all, folks were really looking into using something alive at the time.

Re: RPM
Could you point to the prior art for reference? I was unable to find those examples you mentioned. Also, we may have different/extended restrictions trying to target certain OSs. My plan is to make the build process a part of the transparent CI/CD pipeline (as opposed to Red Hat's standard process to do the builds behind the firewall).

Re: integration tests
AFAIR I looked at those and ported some ideas but not everything there worked smoothly at the time. You say that everything's covered but when I look at https://github.com/ParallelSSH/ssh-python/blob/3c52ff4/tests/test_sftp.py#L372 I see that async related tests are not. Moreover, we're looking into having some e2e tests for our needs (that is when I have some time for it). Also, we do have some integration tests similar to what you have — they spawn sshd and this lib is tested against that. The missing bits are mostly things that we don't need.

That said, what I'm going to be focused on are things that are currently missing from your project. But I'd be open to contributing back eventually if there's time.

[pkittenis]

Re: RPM
See examples from ssh2-python (same dependencies) and system install instructions with system libssh for ssh-python. This is an area others will have more knowledge of.

Re: integration tests
See async api channel and session tests. There are no async SFTP/SCP tests as libssh does not fully support async for SFTP/SCP.
pylibssh seems to have a single integration test only for connecting.

[webknjaz]

pylibssh seems to have a single integration test only for connecting.

That test actually only tests the pytest fixture. And tests in the units folder can be considered integration (they use sshd). Originally I thought I'd add some VM/docker for certain integrations but it's postponed now.

[adelton]

Panos, those assertions reflect my assessment of https://github.com/ParallelSSH/ssh-python/ in March and October 2019 when I looked at it and tried to use it as Paramiko's replacement for Ansible use-cases, with the latest upstream libssh, as well as libssh version in Fedora. Being able to integrate both with the latest versions of libssh for upstream development, and with older versions for cross-OS testing was critical, and at that time, both the technical issues we've hit (and filed), and your explicit stance in ParallelSSH/ssh-python#5

It does not, nor do I have any interest in, supporting versions other than the one embedded.

gave the impression that iterating on the latest bits would be hard with ssh-python. That's why I recommended the Ansible team to go with new lean binding catering to Ansible's use-case over the more generic ssh-python.

It's good to see that the project is back alive and stable but as Sviatoslav explained, the team had to make a decision and it now needs to go with it for foreseeable future. That does not mean that other options aren't possible in the more distant future. Especially if (at least a proof of concept of) Paramiko-compatible interface to ssh-python existed, it would make moving to it easier and not just for Ansible.

Disclaimer: I'm not part of the Ansible team/effort, I was consulted on the options back in 2019 and I showed that the minimal bindings for the use-case are possible.

[webknjaz]

PS - Trying to make SSH libraries be paramiko-compatible is not the best approach IMO.

This is a requirement for our use-case. The old connection plugin already expects this interface and this is what this project is about, it's not just for bindings.

[pkittenis]

That kind of shim code can be more easily written in Python alone if that is a requirement, separately from bindings code.

[webknjaz]

It could, but we had other constraints at the time and there was no need to separate them.

[pkittenis]

Not the sponsor - do not need convincing that is an appropriate piece of work for the task.

[pkittenis]

I could have forked ssh-python to allow for the libssh master integration but I did not want to against your explicit preference of using the released libssh version for the project.

For the absence of doubt, here is the relevant section of the license, found on the top of every file.

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation, version 2.1.

[pkittenis]

Essentially, only after libssh release was made can work start on updating ssh-python for that version.

Work can start at any time and have targeted master branch of libssh in the past. It is, however, more time consuming and personally do not have the resources for it.

If keeping up to date with latest libssh master is important to a vendor, that vendor will need to work on the tooling around that, eg automatically build and test with latest master and make what changes are needed to bindings so can release bindings shortly after. Bindings release should only target released versions of libssh for obvious reasons (should not release with a version of libssh that has not been released).

The concern with this work is that a lot more time and resources is still required to get it ready, as I suspect will be the case. At which point cost analysis may need to be re-done.

[ganeshrn]

The concern with this work is that a lot more time and resources is still required to get it ready, as I suspect will be the case. At which point cost analysis may need to be re-done.

It is already working for the use case that we want and a considerable amount of effort have gone into writing code, testing and CI/CD on top of this library for Ansible network.
Refer https://github.com/ansible-collections/ansible.netcommon/blob/main/plugins/connection/libssh.py
https://github.com/ansible-collections/ansible.netcommon/blob/main/plugins/connection/network_cli.py

and the extensive integration test with tons of module run against different network vendors
Refer the libssh zuul jobs here https://dashboard.zuul.ansible.com/t/ansible/jobs
and eg. job runs https://github.com/ansible-collections/ansible.netcommon/pull/183/checks?check_run_id=1492654099

We are at a stage were adding required missing feature and bugfixes in this library are relatively easy compared to moving to use ssh-python. I wish we had this discussion earlier (maybe in early 2020), but for now, moving to use ssh-python is not considered for foreseeable future.

[pkittenis]

I am happy it works for you, though I suspect there are still much more resources needed.

[pkittenis]

Ah thanks, am new to discussions.

[webknjaz]

No problem, I'm seeing people pointing out similar problems in the discussions feedback repo where GH evaluates how well it goes so I'd say this mistake is pretty common and will probably be fixed at some point.

[ganeshrn]

Even I am new to discussions :-) I realised that I started a new thread while replying to you. Hence I removed that comment and added back as a reply to your earlier comment.

[webknjaz]

Yea... I enabled this to have a place for things that are not bugs. Like StackOverflow-like Q&A.

[ganeshrn]

I am happy it works for you, though I suspect there are still much more resources needed.

I doubt that will be the case with our current scope for this library. If in future we decide to expand the scope of usage I am sure we will re-evaluate and take a call if we want to stick to this library on move on to use the ssh-python.

Alternately if someone wants to contribute to Ansible network collection with new connection plugin using ssh-python library and the corresponding network_cli connection plugin changes even that is welcomed.