Documenting the cables in a SAN

76 views
Skip to first unread message

Knut Karevoll

unread,
Jun 13, 2019, 2:44:43 AM6/13/19
to NetBox
I have just gone to NetBox after having previous experience with Rack::Tables as NetBox offers a much better API. So I may not understand how NetBox is intended to be used. I find NetBox to be much better suited for network documentation in general. However I have had some issues when documenting a SAN we have. I do not expect NetBox to be able to document all the details of an entire SAN configuration. You may be able to add disks as inventory items but documenting the entire topology is beyond the scope of NetBox and beyond our needs.

However it bothers me that there is no form factor for SAS connectors. Having a single source of truth for all your cables is very useful. So not being able to properly document some cables can be an issue. I can see that FiberChanel can be added as network interfaces, but these do use the same physical connectors as Ethernet unlike SAS. So it may be possible to add for example SFF-8088, SFF-8470 and SFF-8644 as form factor for SAS "network interfaces". It would not bother me too much except that about 10% of our cables are SAS cables and they do occasionally become the topic of debate and have to be routed between racks. Having the ability to add them to NetBox may help us reduce on-site visits.

Brian Candler

unread,
Jun 13, 2019, 9:15:21 AM6/13/19
to NetBox
The request for adding more interface types, or user-definable interface types, has been discussed and rejected many times before by the Netbox authors.

See #84 - also #97, #1865, #1941, #2865, #2882, and https://github.com/digitalocean/netbox/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+%22form+factor%22.  SAS was explicitly rejected in #2715 and #659.

We have a few SAS cables, and they have gone into Netbox as interfaces of type "other"; that may be adequate for you.  You can use the interface name and/or description to clarify.

Untitled.png


Christian MacNevin

unread,
Jun 13, 2019, 9:30:37 AM6/13/19
to Brian Candler, NetBox

Perhaps someone will have to build a plugin? A lot of people want this.

 

From: <netbox-...@googlegroups.com> on behalf of Brian Candler <b.ca...@pobox.com>
Date: Thursday, June 13, 2019 at 6:16 AM
To: NetBox <netbox-...@googlegroups.com>
Subject: [netbox-discuss] Re: Documenting the cables in a SAN

 

External email: Use caution opening links or attachments

 

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/b4b1f2f2-d16d-4a7c-9642-3ee01689ef46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

Brian Candler

unread,
Jun 14, 2019, 2:40:06 AM6/14/19
to NetBox
There isn't a GUI or database plugin mechanism in Netbox.  You would have to fork the project, and maintain your fork going forwards.

Knut Karevoll

unread,
Jun 14, 2019, 5:04:08 AM6/14/19
to NetBox
This is quite interesting. It makes me wonder what direction NetBox wants to go in the future. If it aims to be a network infrastructure documentation tool then why document power cables, console cables, FiberChanel cables, etc.? And if it aims to be a DigitalOcean specific documentation tool then why open source it at all? I do also see it argued that there is a finite number of different connectors. I have to point out that this is wrong. Several connector specifications define infinite variants.

The reason why I ask here and not create a ticket is also to find out what others are doing to work around the missing functionality. Do people not document all permanent cables? Are people maintaining their own forks that extends the lists of form factors or other similar static lists? I do appreciate much your suggestion about documenting them as "other" and I have started doing the same, however I do see some potential future problems with this. Having 10-20% of your datacenter cables marked as "other" may be problematic in the long run.

Frank Mogaddedi

unread,
Jun 14, 2019, 5:43:24 AM6/14/19
to NetBox

Knut,

 

I’ve used Netbox since somewhere in V1.x, because it appeared to be pretty much the best thing out there for IPAM. Over time, I’ve come to appreciate all the efforts that went into expanding the DCIM (data center infrastructure management) part, and I’m extremely grateful to DigitalOcean to have open-sourced it. Also a big shout-out to the maintainers, who are not exclusively DigitalOcean anymore J

I’ve noticed that over time, community suggestions have a way to get included, even when the initial response was “we don’t do that”. For instance, I would’ve never thought to see “Power Panels and feeds” included, yet here we are, looking forward to 2.6, and our facilities guys are getting excited. All I can say is that the Netbox team is *much* more responsive to input/suggestions than any pay-for vendor that I’ve encountered. Note, for instance, that the rejection changed from a #659 “we don’t do that” to a #2715 “maybe in the future”.

 

The way I look at it is “Netbox is the best tool for what I need to do”. I put into Netbox whatever I can, and document whatever is missing through other means. Then Netbox gets new or added functionality, and I can ditch yet another spreadsheet and pop the data into Netbox.

 

I understand the prioritization of the team to address “networking related” things first and put “direct-attached” (or other feature requests) on the back burner. I can already run connections between disk-shelf interfaces and controller interfaces, even though the form factor might have to be ‘other’. Of course that’s not optimal, but in my opinion it’s still better than most alternatives.

To that point, your question made me look at the available form factors (which I hadn’t done in a while), and boy, a lot of added things.

 

But that’s just me and my $0.02– Netbox works extremely well for my main tasks and “well enough” for things that are a bit lower on my priority list. And where it doesn’t work, there’s always a spreadsheet.

 

            Frank

 

 

From: netbox-...@googlegroups.com <netbox-...@googlegroups.com> On Behalf Of Knut Karevoll
Sent: Friday, June 14, 2019 05:04
To: NetBox <netbox-...@googlegroups.com>
Subject: [netbox-discuss] Re: Documenting the cables in a SAN

 

This is quite interesting. It makes me wonder what direction NetBox wants to go in the future. If it aims to be a network infrastructure documentation tool then why document power cables, console cables, FiberChanel cables, etc.? And if it aims to be a DigitalOcean specific documentation tool then why open source it at all? I do also see it argued that there is a finite number of different connectors. I have to point out that this is wrong. Several connector specifications define infinite variants.

--

You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.

Jason Guy

unread,
Jun 14, 2019, 9:32:12 AM6/14/19
to Frank Mogaddedi, NetBox
Knut,

To add to what Frank said, the fact that it is open source does not mean they add functionality for everyone's specific use case. They have built a community of users that rely on the tool, and help to make it better. Being open source really means others have the freedom to fix issues and contribute new functionality, via pull request. If the contributed code is written well and complies with the guidelines, they may accept the PR. There is no reason why you can't contribute the SAN functionality to the project. You may have to maintain it yourself for a little while, but you certainly have options. :)

Jason

Christian MacNevin

unread,
Jun 14, 2019, 1:01:25 PM6/14/19
to Jason Guy, Frank Mogaddedi, NetBox

It’s a very good tool with a lot of great thought into it. But at the moment, it’s primarily great at modern data centers, on the ip side.
There is a lot of compromise at the interface level which I don’t claim to understand, eg someone here saying they’re calling BRIs T1s, and
those are different technologies.

More flexibility in some areas would be really appreciated, as well as official support for the plugin concept as a way to trial community
supported feature plugins which could be mainstreamed after some time.

Like I say, the tool is pretty great, and I appreciate the way some of the things fit together. In some ways it surpasses what I first imagined.

 

 

From: <netbox-...@googlegroups.com> on behalf of Jason Guy <jg...@cumulusnetworks.com>
Date: Friday, June 14, 2019 at 6:32 AM
To: Frank Mogaddedi <Frank.M...@nscom.com>
Cc: NetBox <netbox-...@googlegroups.com>
Subject: Re: [netbox-discuss] Re: Documenting the cables in a SAN

 

External email: Use caution opening links or attachments

 

Knut,

 

To add to what Frank said, the fact that it is open source does not mean they add functionality for everyone's specific use case. They have built a community of users that rely on the tool, and help to make it better. Being open source really means others have the freedom to fix issues and contribute new functionality, via pull request. If the contributed code is written well and complies with the guidelines, they may accept the PR. There is no reason why you can't contribute the SAN functionality to the project. You may have to maintain it yourself for a little while, but you certainly have options. :)

 

Jason

On Fri, Jun 14, 2019 at 5:43 AM Frank Mogaddedi <Frank.M...@nscom.com> wrote:

Knut,

 

I’ve used Netbox since somewhere in V1.x, because it appeared to be pretty much the best thing out there for IPAM. Over time, I’ve come to appreciate all the efforts that went into expanding the DCIM (data center infrastructure management) part, and I’m extremely grateful to DigitalOcean to have open-sourced it. Also a big shout-out to the maintainers, who are not exclusively DigitalOcean anymore J

I’ve noticed that over time, community suggestions have a way to get included, even when the initial response was “we don’t do that”. For instance, I would’ve never thought to see “Power Panels and feeds” included, yet here we are, looking forward to 2.6, and our facilities guys are getting excited. All I can say is that the Netbox team is *much* more responsive to input/suggestions than any pay-for vendor that I’ve encountered. Note, for instance, that the rejection changed from a #659 “we don’t do that” to a #2715 “maybe in the future”.

 

The way I look at it is “Netbox is the best tool for what I need to do”. I put into Netbox whatever I can, and document whatever is missing through other means. Then Netbox gets new or added functionality, and I can ditch yet another spreadsheet and pop the data into Netbox.

 

I understand the prioritization of the team to address “networking related” things first and put “direct-attached” (or other feature requests) on the back burner. I can already run connections between disk-shelf interfaces and controller interfaces, even though the form factor might have to be ‘other’. Of course that’s not optimal, but in my opinion it’s still better than most alternatives.

To that point, your question made me look at the available form factors (which I hadn’t done in a while), and boy, a lot of added things.

 

But that’s just me and my $0.02– Netbox works extremely well for my main tasks and “well enough” for things that are a bit lower on my priority list. And where it doesn’t work, there’s always a spreadsheet.

 

            Frank

 

 

From: netbox-...@googlegroups.com <netbox-...@googlegroups.com> On Behalf Of Knut Karevoll
Sent: Friday, June 14, 2019 05:04
To: NetBox <netbox-...@googlegroups.com>
Subject: [netbox-discuss] Re: Documenting the cables in a SAN

 

This is quite interesting. It makes me wonder what direction NetBox wants to go in the future. If it aims to be a network infrastructure documentation tool then why document power cables, console cables, FiberChanel cables, etc.? And if it aims to be a DigitalOcean specific documentation tool then why open source it at all? I do also see it argued that there is a finite number of different connectors. I have to point out that this is wrong. Several connector specifications define infinite variants.

 

The reason why I ask here and not create a ticket is also to find out what others are doing to work around the missing functionality. Do people not document all permanent cables? Are people maintaining their own forks that extends the lists of form factors or other similar static lists? I do appreciate much your suggestion about documenting them as "other" and I have started doing the same, however I do see some potential future problems with this. Having 10-20% of your datacenter cables marked as "other" may be problematic in the long run.


On Thursday, June 13, 2019 at 3:15:21 PM UTC+2, Brian Candler wrote:

The request for adding more interface types, or user-definable interface types, has been discussed and rejected many times before by the Netbox authors.

 

See #84 - also #97, #1865, #1941, #2865, #2882, and https://github.com/digitalocean/netbox/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+%22form+factor%22.  SAS was explicitly rejected in #2715 and #659.

 

We have a few SAS cables, and they have gone into Netbox as interfaces of type "other"; that may be adequate for you.  You can use the interface name and/or description to clarify.

 

Image removed by sender. Untitled.png

 

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/6332bbaa-b488-4ef2-9849-7c0e33258ddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/BL0PR1701MB2626BE9FDDD3197DD846D8FEFBEE0%40BL0PR1701MB2626.namprd17.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

Karevoll, Knut

unread,
Jun 15, 2019, 6:15:00 PM6/15/19
to Christian MacNevin, Jason Guy, Frank Mogaddedi, NetBox
It was not my intention to attack the project. NetBox is a much better tool at both IPAM and DCIM then any other tool I have used and the community is very live and active. I would love to see the project grow which is why I am committing myself to it. The community is much better together then by forking the project.

I was just asking what direction the project the maintainers want to take the project in. Having to find that out after having spent time making patches that gets rejected is not the right way to do it. I have had the unpleasant experience of finding that out the hard way both as maintainer and contributor on other projects.

As to the issue with form factors it is obvious that the current system might have some issues when you start to add even more form factors. So it is understandable if a simple pull request that extends the list gets rejected. You might add a new component category like is the case for power connectors but this too can become very cluttered. I suppose it might be possible to make the lists user extendable either in the database or in the configuration file. RackTables is for example starting off by default with a long list of connectors that can be hard to sort through but lets you add or remove connectors in the database.

You received this message because you are subscribed to a topic in the Google Groups "NetBox" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/netbox-discuss/cl4kBP0rArY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to netbox-discus...@googlegroups.com.

To post to this group, send email to netbox-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Knut Karevoll
Systems Administrator
Xait AS
Reply all
Reply to author
Forward
0 new messages