interface signatures

[hellt]

#377

placeholder for WIP

[kellerza]

@hellt are you still working on this, or can I look into it?

Interface signatures provides the ideal place to add mappings to port names.

Once this exist I want to use it to make port:'s optional in config templates

 links:
    - endpoints: ["sr1:eth1", "sr2:eth2"]
      labels:
        port: 1/1/c1/1, 1/1/c2/1

[hellt]

@kellerza I am not working on this, so you can definitely tap into it
but let's have a design sorted first

How do you see this to work for SR OS? We have multiple hw flavors, some are with breakouts, some are without

[kellerza]

The combination of kind and type is unique. With custom types you will be on your own and back to current behavior. Custom types and the lack of a definition for the kind+type pair is similar, so its an incremental improvement, not all or nothing.

Where to put this is another question, and would appreciate your view.

I'm not seeing any specific go interface / pluggable design for kinds at the moment, so guess today this would be either in config.go (like default passwords), or adding kind specific variables in the clab/<kind>.go file referring to these from config.go (seems to be the current approach for most features).

In python a pluggable design is easy with packages being imported, and understand the go equivalent is interfaces. In the end a go interface design for kinds would give you many static type check benefits, but my intention is not to try throw over the apple cart here.

This PR will only addressing the clab interface names (eth1/eth2) with some slightly stale ports at least until #383 is merged

[hellt]

Yes, I agree with what you said here @kellerza

As long as the kind interface is not yet there (more on this at the end of this msg) I think a function in config.go that returns interface signature map for all kinds/types is ok to go with.

My only requirement here would be that we keep backwards capability. For example both 1/1/c1/1 and eth1 should work for sros sr1s.

PS: interface kind is definitely something I'd like to achieve one day. I failed to quickly hack it, as I hit many circular imports when I tried to shape kinds interface #444

[kellerza]

👍 can have a look at #444

the intention is not to change eth1 to 1/1/c/1, but to have a map between the external and internal names for vm based kinds

Once we have this we could try chaninging link to support 1/1/c/1, or even check if links assigned without gaps, but both these are not the initial step in my view

[hellt]

too stale to pick up
will do a new one