mierdin / ansible-nxapi Goto Github PK

NXAPI will not always return the same fields. Often, if there is a null value for something, that field is just not present.

For example: the number of fields that comes in varies when it's an OSPF route vs static or direct.

So.....RULE NUMBER 1 of dealing with NX-API is that exception handling (specifically KeyError exceptions in Python) is KING.

This should get moved to the NXAPI library when you get around to it.

There are a few places where statically defining dictionary keys, rather than iterating through each key for sub-dictionaries, is actually pretty safe. For instance, each response begins with the same few keys at the beginning.

However, there's a lot of places where you've defined strings of dict keys statically to get things working for a demo. For instance, you statically define OSPF process name. You've tried to place TODOs wherever possible, but the entire thing should be reviewed.

Regarding CDP neighbor tables -

Need to make all the arguments for neighbors similar. like neighborIPv4 vs mgmt_ipv4 - keep it consistent.

Currently when a module running on a single switch need info from another switch, I'm hard-coding in a call to that remote switch using statically defined credentials (the IP is pulled via CDP tables, so that's still dynamic).

A concrete example is if I know a remote switch via CDP (and as a result it's management address) but I want more, like the HOST ID (show license host-id), I have to connect to that other switch via NX-API, even though my Ansible module is currently running against the local switch. As a result I have to statically define the credentials (or make the assumption that the provided credentials for the local switch will work). Not to mention this places additional work on the module, decreasing performance.

This needs to be completely re-designed. Maybe there's an Ansible way to do this better, but I've done it in multiple places now for the sake of getting a working demo together, and it's definitely not ideal.

An idea might be to use something else as a unique identifier - something that's available via CDP. This would prevent me from having to reach out to the remote switch at all - I just need to refer to it via this unique key. This assumes that another module has already gone out and pulled some facts about that remote device and mapped them to this key - a great use case for the get_facts module.

Need to decide whether or not the native facts gathering in Ansible will suffice for your purposes, or continue along the custom method.

Also - Change 'facts' to 'ansible_facts'? http://docs.ansible.com/developing_modules.html (right now the output key is "facts" in your get_facts module)