Interface sequence number can only start from 0 or 1

[julien-duponchelle]

From @adosztal on June 26, 2016 7:2

Two common examples for 4 interfaces:

• eth{0} --> eth0 to eth3
• port{port1} --> port1 to port4

I'm working on a template for Brocade vRouter, which has a weird interface naming: dp0s3 to dp0s6 with 4 interfaces. The problem is I can only name the first interface dp0s0 or dp0s1 (dp0s{0} or dp0s{port1}).

For now I think I'll just name them ethx but would it possible to set the starting sequence number in a later release (maybe 2.0)?

Copied from original issue: GNS3/gns3-registry#141

[julien-duponchelle]

From @adosztal on July 4, 2016 18:28

@noplay, @grossmj?

[julien-duponchelle]

You need something like dp0s{3} ?

On Mon, Jul 4, 2016 at 8:28 PM Andras Dosztal notifications@github.com wrote:

@noplay https://github.com/noplay, @grossmj https://github.com/grossmj ?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/GNS3/gns3-registry/issues/141#issuecomment-230338615, or mute the thread https://github.com/notifications/unsubscribe/AAVFXaIClYjaJsI8K-Qa5C8uJxn4RpN-ks5qSVCygaJpZM4I-gDq .

[julien-duponchelle]

From @adosztal on July 5, 2016 13:51

Kind of, but {1} is already used for segments, which could result in a conflict for other appliances later on. Imagine someone trying to create a template where the first interface is dp0s1; he enters dp0s{1} and gets an error. I know there's a workaround because dp0s1 can be described with dp0s{port1} but this behavior is not consistent.

Maybe dp0s{0,3} where 0 identifies the port and the 3 is the starting sequence number?

[julien-duponchelle]

What do you think Jeremy?

[julien-duponchelle]

From @adosztal on August 1, 2016 5:52

Fix for the suggested format: starting sequence number might be optional, like dp0s{0[,3]}.

[julien-duponchelle]

@grossmj ?

[grossmj]

I think we can adopt that port name format but I don't want to break existing ones.

[adosztal]

It won't. It's an optional extension to the {0} format, and doesn't conflict with the {1} or {port0|1} formats.

[julien-duponchelle]

I didn't look at the code before. But we use Python's format and it's not flexible enough to do that: https://docs.python.org/2/library/string.html#format-string-syntax

By the way, when we will make the web client. I think we will need to move the port formatting on the server and just returning a list of ports to the client. Could be a part of this work (but not for 2.0)

[grossmj]

We will have to find another way to apply the format.

[julien-duponchelle]

If we do that server side we could return in node json a list of ports:

{
  "compute_id": "example.com",
  "console": 2048,
  "name": "test",
  "node_id": "8c1ee491-aed2-48b0-8cc1-0e9e3081ab8f",
  "node_type": "vpcs",
  "project_id": "f46ee563-845f-4835-89c4-b0d924c8e4e8",
  "status": "stopped",
  "port_name_formating": {
     "format" : "Ethernet{0}",
     "first_port_name": "management0",
     "port_segment_size":  0
  },
  "ports": [
    {
      "name": "Ethernet0",
      "short_name": "e0",
      "data_link_types": ["DLT_EN10MB"],
      "port_number": 0,
      "adapter_number": 0,
      "type": "ethernet", # atm, ethernet....
      "link_id": null,
      "link_type": "ethernet" # ethernet or serial
    }
  ]
}

The formating could be done on the controller if the compute has not already set names (case of dynamips).

And client side we should replace the inputs for setting port_name_format, first_port_name... by a dialog with input fields and explanation.

(No idea of the exact amount of work)

[julien-duponchelle]

@adosztal If we support dp0s{port3} it's work for your use case? It seem more easier to implement.

[adosztal]

Yes, that's perfect too.

[julien-duponchelle]

Ok done it's supported now http://api.gns3.net/en/2.0/port_name_format.html

[adosztal]

Awesome, thank you!