Add support for Infiniband interfaces #1598

@callumstrubi commented on GitHub (Mar 8, 2018):

Happy to provide feedback if you need it, though I'm not sure what I'm answering.

@callumstrubi commented on GitHub (Mar 8, 2018): Happy to provide feedback if you need it, though I'm not sure what I'm answering.

adam commented

@Phhere commented on GitHub (Apr 13, 2018):

Maybe it is possible to create a new database table for all interface types? so users can add their own interface types. We could also need MPO (https://en.wikipedia.org/wiki/Optical_fiber_connector)

@Phhere commented on GitHub (Apr 13, 2018): Maybe it is possible to create a new database table for all interface types? so users can add their own interface types. We could also need MPO (https://en.wikipedia.org/wiki/Optical_fiber_connector)

adam commented

@jeremystretch commented on GitHub (Nov 28, 2018):

I'm not familiar with Infiniband myself, so a pull request adding the appropriate types to IFACE_FF_CHOICES would be greatly appreciated.

@jeremystretch commented on GitHub (Nov 28, 2018): I'm not familiar with Infiniband myself, so a pull request adding the appropriate types to IFACE_FF_CHOICES would be greatly appreciated.

adam commented

@DanSheps commented on GitHub (Feb 6, 2019):

This was brought up in IRC as the PR has been put through, and after reviewing some of the documentation, I think this issue should be changed from adding to the form factors to adding to the cable types. My read on Infiniband is that there are two common form factors: CXP & QSFP. The SDR/DDR/FDR/etc are all underlying protocols and cable configurations that are supported by those form factors.

I think it would be a good idea to add "Infiniband" to the form factor list and then add the following form factors:

CXP
QSFP

This follows the same vein as FibreChannel where there is a different procotol at work but they use the same form factors.

Then, include the cables as the data rate definers for Infiniband with:

SDR
DDR
FDR
etc

However, with the recent PR for DAC/AOC cables, we did not define speed there, so that may not be something we want to do with cables either. What is really needed to properly model this is a "module" section where you connect a module, and that module defines the datarate.

My question would be, for someone with an Infiniband switch/device, how does the interface present if you are using a SDR/DDR/FDR etc. Is it defined in the name? If so, then we don't need to worry about the speeds at all.

@DanSheps commented on GitHub (Feb 6, 2019): This was brought up in IRC as the PR has been put through, and after reviewing some of the documentation, I think this issue should be changed from adding to the form factors to adding to the cable types. My read on Infiniband is that there are two common form factors: CXP & QSFP. The SDR/DDR/FDR/etc are all underlying protocols and cable configurations that are supported by those form factors. I think it would be a good idea to add "Infiniband" to the form factor list and then add the following form factors: * CXP * QSFP This follows the same vein as FibreChannel where there is a different procotol at work but they use the same form factors. Then, include the cables as the data rate definers for Infiniband with: * SDR * DDR * FDR * etc However, with the recent PR for DAC/AOC cables, we did not define speed there, so that may not be something we want to do with cables either. What is really needed to properly model this is a "module" section where you connect a module, and that module defines the datarate. My question would be, for someone with an Infiniband switch/device, how does the interface present if you are using a SDR/DDR/FDR etc. Is it defined in the name? If so, then we don't need to worry about the speeds at all.

adam commented

@candlerb commented on GitHub (Feb 7, 2019):

Maybe it is possible to create a new database table for all interface types? so users can add their own interface types.

FYI, that was discussed in #84 and #97 but is currently rejected.

@candlerb commented on GitHub (Feb 7, 2019): > Maybe it is possible to create a new database table for all interface types? so users can add their own interface types. FYI, that was discussed in #84 and #97 but is currently rejected.

adam commented

@DanSheps commented on GitHub (Feb 7, 2019):

From #1865

The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use.

I think this hits the nail on the head. Since the Infiniband interfaces aren't physical interfaces, they shouldn't be included in the list themselves. Instead, an Infiniband category and QSFP and CXP are the way forward IMO.

@DanSheps commented on GitHub (Feb 7, 2019): From #1865 > The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use. I think this hits the nail on the head. Since the Infiniband interfaces aren't **physical** interfaces, they shouldn't be included in the list themselves. Instead, an Infiniband category and QSFP and CXP are the way forward IMO.

adam commented

@cmacnevin commented on GitHub (Mar 14, 2019):

Is there any further movement on this issue? The database / YAML file / whatever for defining our own interface types is still the fastest way to work around limitations in existing supported protocols, but at any rate, Infiniband is important and widely used, and we'd like to incorporate it as a use case.

@cmacnevin commented on GitHub (Mar 14, 2019): Is there any further movement on this issue? The database / YAML file / whatever for defining our own interface types is still the fastest way to work around limitations in existing supported protocols, but at any rate, Infiniband is important and widely used, and we'd like to incorporate it as a use case.

adam commented

@jeremystretch commented on GitHub (Mar 14, 2019):

#2849 is open and awaiting feedback. Have you looked at it?

@jeremystretch commented on GitHub (Mar 14, 2019): #2849 is open and awaiting feedback. Have you looked at it?

adam commented

@cmacnevin commented on GitHub (Mar 14, 2019):

It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks!

@cmacnevin commented on GitHub (Mar 14, 2019): It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks!

adam commented

@DanSheps commented on GitHub (Mar 14, 2019):

It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks!

No, it is a pull request which is requesting permission to merge the change into develop.

@DanSheps commented on GitHub (Mar 14, 2019): > It looks like it was already committed to develop? Any idea when that will be folded into the main release? Thanks! No, it is a pull request which is requesting permission to merge the change into develop.

adam commented

@jeremystretch commented on GitHub (Apr 16, 2019):

For everyone who claims they want to see this added, #2849 has been open for months with virtually no feedback.

@jeremystretch commented on GitHub (Apr 16, 2019): For everyone who claims they want to see this added, #2849 has been open for months with virtually no feedback.

adam commented

@wols commented on GitHub (May 27, 2019):

I do not need an InfiniBand myself, but I would very much like to be able to define my own interfaces:
We have NTP servers witch 4 x Ethernet and 2 x Power Supply (all no problem) and additional

1PPS (BNC)
Serial Timestring (SubD9)

@wols commented on GitHub (May 27, 2019): I do not need an InfiniBand myself, but I would very much like to be able to define my own interfaces: We have NTP servers witch 4 x Ethernet and 2 x Power Supply (all no problem) and additional - 1PPS (BNC) - Serial Timestring (SubD9)

adam commented

@jeremystretch commented on GitHub (May 27, 2019):

NetBox only models network interfaces.

@jeremystretch commented on GitHub (May 27, 2019): NetBox only models network interfaces.

adam commented

@wols commented on GitHub (May 27, 2019):

I understand and accept the argumentation in #84, #97 and #1865.
Strictly speaking, power and console are also not network interfaces - but useful for comprehensive documentation ;-)
My wish is for a complete picture of the necessary connections - achievable with a little flexibility: a user defined list behind "Form factor > Other" can give "Console / Power / Others".
Please!

@wols commented on GitHub (May 27, 2019): I understand and accept the argumentation in #84, #97 and #1865. Strictly speaking, power and console are also not network interfaces - but useful for comprehensive documentation ;-) My wish is for a complete picture of the necessary connections - achievable with a little flexibility: a user defined list behind "Form factor > Other" can give "Console / Power / Others". Please!

adam commented

@jeremystretch commented on GitHub (May 28, 2019):

Strictly speaking, power and console are also not network interfaces

Which is why NetBox uses different models for each of these. The subject of this FR is Infiniband specifically; let's keep the conversation on-topic please.

@jeremystretch commented on GitHub (May 28, 2019): > Strictly speaking, power and console are also not network interfaces Which is why NetBox uses different models for each of these. The subject of this FR is Infiniband specifically; let's keep the conversation on-topic please.

adam commented