Should open() arguments in the ConnectionPlugin Abstract Base Class be move to be bound to the object

Should these arguments just be bound to the object?

    @abstractmethod
    def open(
        self,
        hostname: str,
        username: str,
        password: str,
        ssh_port: int,
        network_api_port: int,
        operating_system: str,
        nos: str,
        connection_options: Optional[Dict[str, Any]] = None,
        configuration: Optional[Config] = None,
    ) -> None:

It seems like we are doing a lot of passing around of shared state which might not be necessary.

This relates to #202 (i.e. how many arguments actually are there/will there be)

This might also enable the glue-code for processing the connection arguments (which is currently in the connection plugins) could be moved to a common method self.process_args which returns a dictionary of arguments.

So then the end napalm driver would just look something like this (the open method):

    # napalm
    def open(
        self,
    ) -> None:

    parameters = self.process_args()
    network_driver = get_network_driver(nos)
    connection = network_driver(**parameters)
    connection.open()
    self.connection = connection

The netmiko driver would be very similar.

This would also make testing of the argument processing easier (which I am running into on PR #216)

[dbarrosop]

What I like about this is that it simplifies the connection plugins.

I think it is effectively the same exact code, the only difference is you are shortening the signature by sorting data in the class which has a benefit and two drawbacks in my opinion:

1. Benefit, signature is shorter.
2. Drawbacks:
   1. It requires to keep unnecessary data in the class which is ok if you are managing a few hundred of devices but it may be a problem when going up to the thousands or tens of thousands. It’s basically going to make the code slower and heavier.
   2. It hides the parameters the open connection can use, which simplifies the signature but makes the code look more like “magic”.

of having a common _process_args()

I don’t think so. I mean, the magic to resolve the arguments should be in the Nornir object, the connection plugin shouldn’t bother with business logic. So the only thing the plugin has to effectively do is map the attributes to the right argument. I think this will look clearer though once we work on #202

Let me summon @dmfigol and @ogenstad and see what they think. As I said, I am a bit ambivalent about this as I think the pros/cons have more or less the same weight so I’d like to hear more opinions.

[ktbyers]

Okay, let’s leave it as-is. I will just go ahead and close this PR.

Yes, I totally agree on _process_args(), I think it is probably useful to have this, but we can do that independent of binding the arguments to the object. I also agree that it doesn’t needs to be mandated by the abstract base class.