New driver: eos_ssh for Arista devices without API

[TheRealBecks]

For an internal project I needed to create eos_ssh as a new driver as we have the EOS API not licensed (yet) and also not configured on our Arista devices. eos_ssh is a work in progress and I really like to contribute this driver to NAPALM, but first I wanted to know if you would integrate that driver?

It's not yet finished, but working great so far. If I get a GO from you I will work further on that project. So what do you think about that driver? :)

[mirceaulinic]

Hey @TheRealBecks. I'd give that a 👍 as I'm well aware of the challenge with the eAPI licensing. I'm not sure what approach you've been working on, but I'd suggest the following to minimize the amount of code we're maintaining (and, implicitly, your work 😉) while re-using the existing code.
The core idea is that from the CLI you can get the JSON output you'd normally get over the eAPI, by simply adding | json to the usual command. AFAIK, the support for this is going sufficiently back in time for this.

In brief:

• Have another choice for the transport optional argument, ssh which users can select, yet https should always remain the default value.
• Define an internal helper method that depending on the transport used, invokes either self.device.run_commands( or adds | json to the command and loads the JSON document, e.g.,

def _run_commands(self, commands):
    if self.transport == 'ssh':
        ret = []
        for command in commands:
            cmd_pipe = command + ' | json'
            cmd_txt = self._netmiko_device.send_command(cmd_pipe)
            cmd_json = json.loads(cmd_txt)
            ret.append(cmd_json)
        return ret
    else:
        return self.device.run_commands(commands)

Something along these lines. the self._netmiko_object would be initialized during open() when the transport of choice is ssh.

• In every of the existing methods, instead of executing self.device.run_commands, you'd invoke that newly defined method, e.g., this line: https://github.com/napalm-automation/napalm/blob/develop/napalm/eos/eos.py#L326 would become:

result = self._run_commands(commands)

I think that'd work well. Let me know if you have any questions or other thoughts!

[ktbyers]

I would be okay with doing this as long as we do this in the way Mirceau describes. In other words, there is no parsing and everything is done via | json and all the commands/mechanisms are essentially or very close to essentially the same.

Or worded differently, we would basically be saying that SSH is just another transport and that we won't be doing any screen-scraping in the driver.

Sound reasonable to everyone?

[thomasbridge74]

I've run into a similar situation regarding access to the EOS API and was wondering about using ssh rather than https to connect to the devices from napalm. I don't see any thing in the code base that suggests this ever got integrated? If I were to make an effort to implement the ssh driver, would that still be welcome?

[mirceaulinic]

Sure thing, @thomasbridge74 - as long as your implementation aligns to what we've discussed above, we'd welcome your contribution! 😉

[thomasbridge74]

I've just submitted a (WIP) pull request for some feedback. Please be gentle :)

[mkhachfeh-godaddy]

Any progress on this topic?

[mirceaulinic]

Yes, this is now available in release 4.0.0, see https://github.com/napalm-automation/napalm/releases/tag/4.0.0.