You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
When setting up an AiiDA computer, I often encounter a problem that, despite ssh being configured and working, the verdi computer test command fails. This is because relationships between the core.ssh transport plugin and the ssh configuration found in .ssh/config are somewhat convoluted.
This specific point was causing a lot of frustration when using AiiDA because I was never sure that my newly set up computer worked fine.
In addition, the ssh configuration requires several parameters, which are not transferred when the computer is imported into a new database. From this point of view, there is no reason to store the connection information in AiiDA.
Describe the solution you'd like
I propose implementing a simplified plugin that exclusively relies on the .ssh/config. This will drastically minimise the effort to configure ssh transport for a computer. This approach will ensure that if ssh works, the verdi computer test will work too. Well, most likely 😅 .
I would base this plugin on fabric, which is a more high-level library w.r.t. paramiko and is recommended by paramiko developers for high-end client applications.
Describe alternatives you've considered
I also considered using the asyncssh library as an asynchronous alternative to fabric/paramiko. But it turns out that relying on asyncssh is a challenge currently. Since AiiDA has some asynchronous methods and there can be only one event loop, the following appears to be impossible:
async function from aiida -> sync transport plugin method -> async method from asyncssh
Therefore, at the moment, we stick with fabric, which provides high-level ssh functionality.
Additional context
The current implementation of the ssh transport plugin tries to provide users with a very fine-tune configuration. But the further one goes, the more complicated and prone to errors it becomes.
I believe that using the dedicated library to automatically handle the ssh configuration is the right way forward.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe
When setting up an AiiDA computer, I often encounter a problem that, despite ssh being configured and working, the
verdi computer test
command fails. This is because relationships between thecore.ssh
transport plugin and the ssh configuration found in.ssh/config
are somewhat convoluted.This specific point was causing a lot of frustration when using AiiDA because I was never sure that my newly set up computer worked fine.
In addition, the ssh configuration requires several parameters, which are not transferred when the computer is imported into a new database. From this point of view, there is no reason to store the connection information in AiiDA.
Describe the solution you'd like
I propose implementing a simplified plugin that exclusively relies on the
.ssh/config
. This will drastically minimise the effort to configure ssh transport for a computer. This approach will ensure that ifssh
works, theverdi computer test
will work too. Well, most likely 😅 .I would base this plugin on
fabric
, which is a more high-level library w.r.t. paramiko and is recommended by paramiko developers for high-end client applications.Describe alternatives you've considered
I also considered using the
asyncssh
library as an asynchronous alternative tofabric
/paramiko
. But it turns out that relying onasyncssh
is a challenge currently. Since AiiDA has some asynchronous methods and there can be only one event loop, the following appears to be impossible:Therefore, at the moment, we stick with
fabric
, which provides high-level ssh functionality.Additional context
The current implementation of the
ssh
transport plugin tries to provide users with a very fine-tune configuration. But the further one goes, the more complicated and prone to errors it becomes.I believe that using the dedicated library to automatically handle the ssh configuration is the right way forward.
The text was updated successfully, but these errors were encountered: