WIP: Prototype driver to talk to Dellos9 switches using ansible networking modules.

[naved001]

Still a work in progress, I am opening this to start some discussion and gather some feedback.

Few things:

1. The test switch I am using is a Dell S3048-ON running Dell OS9.
2. I am using the dellos9_config module to set the vlans and turn on switchport. And the dellos9_commands to gather port information (is port on or not, trunk and native vlan information).
3. There's this dellos vlan role which can set vlans on dellos6,9 and 10. I might try that in the future but is there a role equivalent to dellosX_commands? That way the driver can be truly generic, at least for the dell switches. The dellos9_config module only acts a transport for my commands. I still have to write the commands in a way the particular switch can digest.
4. I have a cisco switch which supports the nicer nx-os modules, I'll try and see how that plays.

I can run the methods from the interpreter, but when I run our test suite, I get some errors from ansible_runner. Haven't really looked into it yet.

cc: @zenhack @privateip

[naved001]

okay, everything is functional now at least. tests/deployment/vlan_networks.py took 290 seconds to run using ansible compared to 150 seconds with the curernt HIL driver (which uses REST API CLI).

[zenhack]

Hm, hopefully using the roles will give us some portability. If not I don't see what we're getting out of this; the current implemenation is more code, brings in an extra dependency, and is apparently twice as slow. But it seems like we'll still need to have per-vendor drivers at least for a while, though maybe not per-model.

[privateip]

I have doubts about how this implemented. I would have expected the code to be completely generic and wrap around the role for implementation. The role can handle the abstraction northbound into HIL and implement device specific calls southbound towards the device. In this way there would only have to be a single Ansible driver and the role would handle the device specific interactions.

Adding support for new platforms becomes as easy as updating the role and not having to touch the code path. So adding support for vendor XYZ is a matter of adding the device specific implementation into the role (or even the lookup path). In fact, the role allows for specific implementation to be build on a per device / per connection type basis. In this way, the implemenation only needs to concern itself with the data exchange between Ansible and the HIL driver and not code device specific calls into the driver.

With regards to the performance, I would need to dig into this a bit more to understand how the performance is being measures. I would expect a light bump in performance as we are invoking an external process (Ansible) to handle the device configuration.

[naved001]

I would have expected the code to be completely generic and wrap around the role for implementation.

I agree. I kind of tried to split the driver into two files, with ansible specific code in one file (which I hard coded to use the dellos9 modules, just to get something working and to compare performance).

The role can handle the abstraction northbound into HIL and implement device specific calls southbound towards the device.

That sounds ideal and I'll update this PR to use that instead. Is there some generic networking role that I can use? I could only find the Dell vlan role which I linked to earlier.

With regards to the performance, I would need to dig into this a bit more to understand how the performance is being measured.

I ran our networking tests (which perform a bunch of networking operations on the switch) using pytest which returns how long it takes to run.

Thanks for the feedback @privateip!

[naved001]

Something like this perhaps https://github.com/openstack/networking-ansible/tree/master/etc/ansible/roles/openstack-ml2 ?

[zenhack]

There's a bit of the portability story that's just not sticking to my brain: as far as I can see, the existant ansible roles and modules are all at least vendor-speciifc (if not device specific). I don't see how we can lean on ansible for portability given that it doesn't seem to actually expose a device-agnostic interface to role authors? Do you guys have plans to build a portable interface like this? What am I missing?

[naved001]

Just to keep folks updated, I'll get back to working on this next week (a more generic version that uses roles).

[privateip]

@zenhack sorry for the tardiness on my side.

Do you guys have plans to build a portable interface like this?

Yes, the work is well underway to have a more generate entry point role that will provide the level of abstraction you are looking for. The initial build is currently moving upstream into ansible networking right now and I will follow up here with a link to that effort as it comes.

[zenhack]

Good to hear. Maybe it makes sense to defer most of the HIL work until that's available? Per the above, I don't know that it makes a ton of sense for us to write vendor specific drivers.