Adding a pair of proxy and execution modules for managing Arista switches via the pyeapi

[mirceaulinic]

What does this PR do?

Adds the initial version of two new modules: one Proxy and one Execution module for managing Arista switches via pyeapi which is the official library from Arista, using the eAPI.

The execution module is flexible enough to execute the commands to the remote device without necessarily requiring to be running inside the pyeapi Proxy Minion. I named the modules arista_pyeapi, as I will provide a set of modules for managing Arista switches without having the pyeapi external dependency without necessarily having feature parity with arista_pyeapi (as that would imply rewriting a good part of the pyeapi library into Salt).

[cachedout]

We have nearly identical code over in netmiko_mod. Refactor for DRY?

[mirceaulinic]

Apologies for late reply @cachedout. Yes, there's a little overlap between them. We could have the following function in the utils:

def prepare_kwargs(all_kwargs, class_init_kwargs):
    for karg, warg in six.iteritems(all_kwargs):
        if karg not in class_init_kwargs:
            if warg is not None:
                fun_kwargs[karg] = warg
            continue
        if warg is not None:
            init_args[karg] = warg
    return init_args, fun_kwargs

Then the code in this execution module would become:

def _prepare_connection(**kwargs):
    '''
    Prepare the connection with the remote network device, and clean up the key
    value pairs, removing the args used for the connection init.
    '''
    init_args = {}
    fun_kwargs = {}
    pyeapi_kwargs = __salt__['config.get']('pyeapi', {})
    pyeapi_kwargs.update(kwargs)  # merge the CLI args with the opts/pillar
    init_args, fun_kwargs = salt.utils.args.prepare_kwargs(pyeapi_kwargs, PYEAPI_INIT_KWARGS)
    if 'transport' not in init_args:
        init_args['transport'] = 'https'
    conn = pyeapi.client.connect(**init_args)
    node = pyeapi.client.Node(conn, enablepwd=init_args.get('enablepwd'))
    return node, fun_kwargs

I'm not disagreeing, just that I'm not sure if it's really worth it, particularly as it's harder to port a module in an older Salt version due to the utils dependency.
On the other hand, I have a couple of more modules pending in the queued to be submitted, that would have the same code as well.

What do you think would be the best? Thanks!

[gtmanfred]

If you use __utils__['args.prepare_kwargs'] they should just have to drop the newer args module into salt://_utils/ and sync them and it should be easily portable.

[mirceaulinic]

Fantastic, I will do it like that then - will refactor and push tomorrow morning. Thanks guys!

[cachedout]

Same here. Code is in the netmiko module. Refactor for DRY?

[mirceaulinic]

Hi @cachedout - I have pushed dddef49 to remove the redundant code. I will follow up with another PR for Netmiko to use the new args.prepare_kwargs util function.

CC. @gtmanfred @rallytime

[rallytime]

I have two small changes that are needed.

[rallytime]

We also need to import print_function and unicode_literals here.

[rallytime]

Same comment here.

[cachedout]

I'm good here now. Thanks, @mirceaulinic. If you can get the changes suggested by @rallytime in then I think we're good to go here.

[mirceaulinic]

Okay, added 2b61f5d to solve the imports.

[mirceaulinic]

Bump @cachedout @rallytime - apologies if I'm pushy, but I'd love to have this in so I can follow up with the next PR which depends on this (of course, if you are happy with the code), so I can finish before the 6th of Aug. Thanks!

[rallytime]

@mirceaulinic It's merged now. I was off yesterday so I hadn't see then notification yet. :)

Thanks for working on all of this for the feature release! We appreciate it, as always. :)

One thing - I know you've been adding a bunch of new modules - can you make sure you get those listed in the Fluorine release notes?

[mirceaulinic]

Yes, thanks for reminder @rallytime. I will surely add them to the release notes too!