Break out Brocade adapter for different devices?

[LindsayHill]

Brocade has 3 main IP lines - MLX, ICX, VDX. Each run a different OS (NetIron, FastIron, NOS) respectively. There is of course also the FC line, running FabricOS

What's your thoughts on breaking the Brocade adapter up into separate adapters? Something like Brocade_ssh_mlx, or similar?

If I can, I might be able to help with getting initial adapters going for these. Funnily enough, I can get access to some test Brocade gear :)

[ktbyers]

@LindsayHill Yes, I want to standardize on the following naming convention:

vendor_platform

For example,

cisco_ios cisco_asa cisco_nxos hp_procurve

In this file https://github.com/ktbyers/netmiko/blob/master/netmiko/ssh_dispatcher.py

I have:

CLASS_MAPPER_BASE = {
    'cisco_ios': CiscoIosSSH,
    'cisco_xe': CiscoIosSSH,
    'cisco_asa': CiscoAsaSSH,
    'cisco_nxos': CiscoNxosSSH,
    'cisco_xr': CiscoXrSSH,
    'cisco_wlc': CiscoWlcSSH,
    'arista_eos': AristaSSH,
    'hp_procurve': HPProcurveSSH,
    'hp_comware': HPComwareSSH,
    'huawei': HuaweiSSH,
    'f5_ltm': F5LtmSSH,
    'juniper': JuniperSSH,
    'brocade_vdx': BrocadeVdxSSH,
    'a10': A10SSH,
    'avaya_vsp': AvayaVspSSH,
    'avaya_ers': AvayaErsSSH,
    'linux': LinuxSSH,
    'ovs_linux': OvsLinuxSSH,
    'enterasys': EnterasysSSH,
    'extreme': ExtremeSSH,
    'alcatel_sros': AlcatelSrosSSH,
    'fortinet': FortinetSSH,
    'dell_force10': DellForce10SSH,
}

So currently I have brocade_vdx.

It sounds like there should also be:

brocade_icx brocade_mlx

Is it more logical to name it this way or brocade_netiron, brocade_fastiron, etc?

You can see this file for some details on adding a vendor:

https://github.com/ktbyers/netmiko/blob/master/VENDOR.md

Note, the brocade_ssh.py file should probably be renamed to brocade_vdx_ssh.py. This is a pretty easy fix since it should be transparent to people that use Netmiko.

[LindsayHill]

VDX / ICX / MLX is the hardware family, whereas nos/fastiron/netiron is the OS family, so it probably is better to go with brocade_netiron, etc. Seems a better match to the way you've gone with IOS/IOS-XR, etc.

[ktbyers]

@LindsayHill I stubbed out the Brocade support in this commit. Fastiron and Netiron don't do anything currently (just raise an error).

This should create the framework, however.

If they are Cisco-like in behavior, then they probably will work without much modification.

Let me know if you want to test netiron or fastiron out and we can create a test script.

[LindsayHill]

Thanks @ktbyers. FastIron & NetIron do look Cisco-ish. Can do some tests pretty quickly against netiron, and it shouldn't take me long to get some fastiron boxes. I do need to do some reading up on your testing infrastructure. If you've got scripts to gather data that you want me to run, let me know.

Will be in Bay Area over the next two weeks, might see you around

[ktbyers]

@LindsayHill

Here is the doc on testing:

https://github.com/ktbyers/netmiko/blob/master/TESTING.md

I would start by just copying the 'cisco_ios' versions in (in the .example files).

You going to be up in San Francisco?

[LindsayHill]

Thanks @ktbyers , I'll take a look and run it against some real kit this week.

Will be staying in San Jose area, may be up in SF area at some stage. Will get in touch if I'm heading that way.

[LindsayHill]

I've been doing some testing with brocade_nos, and so far everything looks good. In the next few weeks I'll do some tests with MLX & ICX. Good chance of code changes needed there. Is it worth submitting some updates to the commands.yml.example, responses.yml.example and test_devices.yml.example files?

[ktbyers]

@LindsayHill Yes, it is worth submitting those files. That would make it easier for me to improve the automated testing in the future...thanks.

[LindsayHill]

Cool. I'll put together some PRs. I'll do some testing of MLXe & ICX, and wrap stuff up in one change. May be a few small code changes required for MLXe/ICX.

[ktbyers]

Sounds good.

[LindsayHill]

PR #234 submitted for ICX support

[ktbyers]

I am going to close this issue as we probably don't need this placeholder any longer.