Support for devices not associated with a rack #198
Comments
jeremystretch
changed the title
|
Add cable inventory (ethernet, fiber, etc) to this. I was messing around with OpenDCIM a few months ago and that has the concept of generic supply bins that you can classify as whatever you want and put inventory in them...although it is implemented very poorly. |
|
I think inventory (spare parts and consumables) will probably best be implemented in a separate app/module. Would be easier to have it exist separately and have loose ties to the dcim device side of things. |
|
I feel like this is widening the scope of NetBox too far. Tracking devices which are not installed within racks significantly disrupts the NetBox relational model (which boils down to device -> rack -> site). You can manage PoE devices (WAPs, phones, cameras, etc.) reasonably well by assigning them to the rack in which their parent switch is located and annotating their location in the commends. (And in the near future we'll introduce custom fields so you can assign a room number, for example.) But anything beyond that I think crosses into facilities management and wouldn't be a good fit for NetBox, which will always be network-centric. |
|
I'd argue spare inventory management probably still makes sense for the network (sfps, modules, etc.) and DCIM. Even with that said, I would say this should be pushed off to focus on other more pressing network centric @jeremystretch, I get your point, but maybe we should define scope of this project better. My understanding would be that if netbox is about DCIM, spares are a part of DCIM just like support contracts. @peelman may be right here, it feels like this would be a separate module that you could associate to a site or rack group/room. |
|
I definitely think Inventory should happen, and definitely in a separate module. I understand @jeremystretch's reservations as well; but i feel like forcing a rack-centric approach is stopping at the waters edge. My thought is (take it or leave it, I'm just floating the idea):
That leaves the rack-organizing bits alone and lets them continue to work as needed, but allows users/admins to structure the location of objects (including racks) how best fits their needs. That structure could almost completely supplant the |
|
There are several ways to skin this cat.
|
|
I will say that in the Rails world, the ancestry gem makes implementing a tree structure for a model dead-simple. I don't know that such power is necessary, or if there a [simpler] alternative already exists in Django. With the above Gem, it was trivial to build a helper method to generate either a table with the appropriate nesting/indentation pattern, or similarly I've ran down these alleys before building asset management systems. Rigidity is not your friend, especially in a disparate and heterogenous environment like almost all networks are. Your models should be abstractions unless there is a good reason for them not to be, not rigid without good reason to be abstract. |
|
I would be interested in this also. We currently use Openstack and the VM's are provided by another organization so rack location does not matter to us since we just care about the VM's and not physical hardware. Right now I'm using rack's name to figure out each tenant in Openstack. |
|
Would it be possible to add vertical bars on the sides of the racks for the Zero-U devices (PDUs) to live? It is very helpful to have all the items in the rack as a part of the rack diagram. |
|
While I really like the self-nesting location idea, an alternative workaround for the short term may be to simply create yourself a "Unracked Items Rack." That was my first thought when I saw that Rack was a required field for Devices. The benefit to this approach is if you're setting up items in a lab environment prior to production you can create the devices and get them ready, imported, and addressed before they are even racked up. Then when you're ready simply move them from the "Unracked" rack to the proper location. |
|
That is what I did as a temporary solution. I used the custom fields to On Tue, Oct 25, 2016 at 4:54 PM, mryauch notifications@github.com wrote:
|
I would like to see this self-nesting also apply for devices within devices, i.e. it replaces the parent-child device hierarchy as well. It solves the problem that a device can't be both a parent and a child (e.g. an SFP plugs into a WIC which plugs into a line card which plugs into a router). It's also logical. A blade server is a home for blades, in the same way as a rack is a home for rackable boxes, and a room is a home for racks. This has a potential impact on visualisation. Right now you can visualise a rack, but not a site floorplan (#114) and not the child devices within a device. Ideally you would be able to visualise at every level. A generic approach may be possible (e.g. a location has a grid which is X units wide and Y units high. Maybe additionally some named locations like "PSU Slot 1" and "PSU Slot 2") This could also solve the issue of half-width rack items. You could take a location in a rack which is 1U high, insert a virtual container which has two horizontal slots, and then put a half-width unit into each of those slots (e.g. Cisco ASA5505).
This works pretty well, since netbox lets you associate a device to a rack without giving it a vertical position. I think it works well for the "spares inventory" problem at the level of Devices. You can easily select a device from a spares pile, and update its Site/Location when you want to move it. The only problem is that every device must be assigned a 'name' even when it's a spare. It's not great for Child Devices. You can't navigate to the child and set its location inside another device. Rather you have to navigate to the new parent, select the bay, then add the child. That's OK but it means you have to be able to identify the child by it's fake "name", and at that point you can't search by its serial number or asset tag or current location. It's unworkable for Modules though. You can't move a module from device A to device B - you have to delete it from A and add a new module to B. Plus, you would need a fake device for spare modules to sit in. (However, personally I'd just get rid of modules entirely. They are a constant source of irritation, as you have to decide whether to best model something as a module or a child device) |
This function is served by device bays, which represent one device installed within another. This relationship is intentionally limited to a single level of depth.
These aren't independently managed devices; they're components of a device (currently represented by modules). See #824 for discussion around extending this concept. The idea of a recursive hierarchical model might seem appealing at first, but it's a lot more trouble than it's worth. For one thing, each tier of objects has unique characteristics and validation needs. For example, a site has an address; a rack has a height and width; a rack group has neither. Trying to shoehorn these very different concepts into a single model isn't going to work well. The simplest approach here might be to add a However, this would introduce a need for additional validation; for example, to automatically update devices if a rack is moved from one site to another. This can probably be handled well enough by employing signals, but I'll have to give this some more thought. If having a device associated only with a site (and not with a specific rack within that site) is sufficient to meet the requirements of this feature request, I think this is a reasonable solution. However, if there's a desire to introduce some new container model that sits in parallel to the Rack model, further discussion is needed. (Note that we don't want to confuse the concept of nonracked devices with spare inventory tracking here, as the two are separate concepts.) |
I couldn't find a separate ticket for "spares" yet. Is it time to create one? I accept that spares have a different set of requirements. For example, a spare device won't have a "name" in the way that an in-service device does, although it would be useful to remember its in-service history (*). However we need spares of modules as much as we need spares of devices, and this I think will force a change in the way modules are modelled. At very least, it will be necessary to be able to remove a module without destroying it. And there will be module types, and modules will have serial numbers. I do find the device / module dichotomy a source of ongoing confusion and pain. Take the example of a chassis switch:
The guiding principle that a "device" is "independently managed" appears to break down here. The chassis itself is dumb, but it must be a Device, since it takes up rack units. The management card is an active device that you can talk to, which suggests it is a child device. However if you have a redundant pair of management cards, you can equally argue that they are modules; there is only one active at a time providing the management address, so logically the management address belongs to the entire chassis, not to card A or card B. Otherwise you have to model (say) card A as having a management address, and card B having none. As for the line cards, they are not independently manageable, which suggests they are modules. And yet from a physical view and a spares / inventory point of view, a card is a card; and indeed in some chasses the slots are equivalent and interchangeable. If a management card is a device, then isn't a line card as well? Then if a line card takes modules (like WICs) then this also pushes us towards "line card == device" - but only because modules can't contain modules. In other words, that's a case of adjusting your world view to match what the data model allows. A couple of other thoughts. (1) On the physical side, in the end there are things. A thing may or may not be IP manageable. A thing may have a serial number or not. A thing may sit inside another thing, or it may sit inside a rack, or it may sit inside a site but not in rack. Personally I lean towards each of those places being a "location", as it gives more flexibility to accurately model the world rather than force the data into a fixed model. Certainly there is a trade-off though. Some problems go away (e.g. the issue that a Device has to point to both a Rack and a Site and that information has to be kept consistent). Other problems arise (e.g. the set of fields you want to hold on a Rack may not be the same as the set of fields you hold on a Site). But that just means you need to categorise locations. (2) If the "Device" means the role something plays, i.e. its function in the network, then maybe this can be entirely decoupled from the physical asset providing that function. Consider for example you have switch sw1.example.com, and it fails, so you replace it with another switch from inventory. You configure up the new switch in the same way as the old, and you patch it up in the same way too. Afterwards the new switch is called sw1.example.com, and the old one has the label removed. Ideally, in Netbox you don't want to update all the inventory details on sw1.example.com (e.g. serial number, asset tag, purchase date) to match those of the replacement item. But neither do you want to copy all the IP addresses and connections from the old sw1.example.com onto a new device, and remove the them from the old device - plus move the name "sw1.example.com" from the old device to the new. I think you just want to unlink the "sw1.example.com" role from the old hardware asset and link it to the new hardware - job done. "sw1.example.com" then becomes something of a virtual function, linked to the physical asset performing that role at the current point in time. Such a separate physical asset matches nicely with the requirements of spares/asset tracking.
I'd be inclined to put that consideration at the bottom of the pile. Even if an inventory database has a million items in it, these days it's going to sit entirely in RAM. (*) "Spares" implies things waiting to be put into place, but in practice what happens is this: we buy device with serial number X. It sits in a pile for a while; it gets installed into a rack where it's called "foo.example.com"; it gets removed and shipped back to manufacturer for repair; it gets returned into another pile. I care mostly about where it is right now, but the history trail is valuable too, including what function it was performing and when. I think that things which are currently considered "modules" are valuable assets which need tracking in this way too. For example, we have a constant churn of hard drives and SSD drives being returned to vendor for repair or replacement under warranty. Apologies for long rambling post :-) |
Both of these are modules. A management card does not function on its own, only when installed in a chassis. The chassis is the managed device. If I say I'm going to swap out the routing engine in a Catalyst 6500, you don't assume that the device is getting a new name and IPs, right? Ultimately, the site/group/rack/device hierarchy that exists today is integral to the way NetBox functions and isn't going to change much (save for the introduction of regions, which should be added in the near future). This set of relationships and the validation around them is where NetBox provides much of its value. |
Indeed. But equally, if I replace a monolithic device (like a 1U switch or firewall) I also give the replacement device the same name and IP address as before. The name and address goes with the role. If a line card is a Netbox "module", then this limits your ability to have a line card with slots (e.g. a WIC slot). You can add a WIC to the parent device, but lose the information as to which line card it's in. Aside: an interesting example is a failover pair of ASA5500-X firewalls. With this setup, Cisco have completely decoupled the hardware from the function. What I mean is: on the hardware side, you statically define one box as "primary" and the other box as "secondary". But on the IP side, you have an "active" and a "standby" device. The boxes never change whether they are primary or secondary, but the active/standby roles can swap over. So you might configure an interface like this: The address 192.0.2.1 always goes with the currently "active" device, and the 192.0.2.2 address with the "standby" device. If both devices are up and running, the two boxes could be in these states:
or
If you make an ssh connection to address 192.0.2.1, you will hit whichever box is performing the "active" role; ssh to 192.0.2.2 to the "standby" one. There is no way to connect to the "primary" box or the "secondary" box. |
|
Right, this is the concept of a virtual chassis or cluster, which isn't supported in NetBox and probably won't be in the near future given how difficult it is to model. We've gotten pretty far off-topic so let's wrap up the conversation here. I think we have a pretty workable approach to support non-racked devices with the existing scheme. |
…munity#902) * Initial work to support rackless devices * Updated device component connection forms * Updated IP address assignment form * Updated circuit termination form * Formatting cleanup * Fixed tests
Would be nice to support devices that aren't racked or even part of a rack, but are just in a Location. This can be cheated somewhat, but as the DCIM/ITAM side of things grows, it will become more and more relevant. Some examples:
Not to mention desktops, laptops, tablets, monitors, etc.
The text was updated successfully, but these errors were encountered: