Add HPE DL360,DL380,DL560,DL580 Gen9 and Gen10 devices

[weidi]

[m2martin]

Hello @weidi,

I'd recommend to use the possibility to add modular components (since Netbox 3.2.0) for new templates.
E.g. the ProLiant servers have module bays for power supplies, Flexible LOM, HDD cages, each with different types of possible modules.

This allows the user to populate the bays with the components which are actually used.

[weidi]

Good point, will look like this or anything to add?

[m2martin]

I didn't compare it with the datasheet but it looks fine from a logical point of view.

One more hint: You can use the {module} variable in a module-type to have entities in a deployed module dynamically named based on position of a module-bay.
You can make use of it for example for PSU bays (e. g. with position: A and position: B) to have the resulting power-ports dynamically named to e.g. Power (PSU A).

[weidi]

I didn't compare it with the datasheet but it looks fine from a logical point of view.

One more hint: You can use the {module} variable in a module-type to have entities in a deployed module dynamically named based on position of a module-bay. You can make use of it for example for PSU bays (e. g. with position: A and position: B) to have the resulting power-ports dynamically named to e.g. Power (PSU A).

Thank you for the hint. Implemented position for the module bays now.

[weidi]

Added 5 models more

[bbrk364]

with Server, you can not enumerate like a switch and too many option for card in the PCE-e slots

[weidi]

with Server, you can not enumerate like a switch and too many option for card in the PCE-e slots

I'm happy to remove the modules if you mean this ? Enumerating pcie is not a problem, they have a slot number that is recognized in the OS as well.

[ryanmerolle]

@jeremystretch another interesting use of module bays for PSUs and PCI. I can see how PCI could be considered module bays, but the whole thing feels like the focus was network device line carrds. Thoughts?

[weidi]

@jeremystretch another interesting use of module bays for PSUs and PCI. I can see how PCI could be considered module bays, but the whole thing feels like the focus was network device line carrds. Thoughts?

I see modules make sense also for psu and pcie bays as that slots can host so many different devices and everybody is free to populate them as needed. The disk boxes might be a bit too much indeed. Just let me know your thoughts and I will implement it.

[m2martin]

For me it would make sense to treat any entity which generates additional types of connections as modules. For example, a server could have one or two (or more) power connections depending on the installed PSUs and arbitrary types of network connections depending on the installed network cards. Otherwise, HDDs are just informational, I think. Here, inventory items would be applicable.

But I already enjoy the discussion about the possibilities which were introduced with the modular modeling :smile:

[ryanmerolle]

We are trying to figure this out. Please voice your opinion here:

• netbox-community/netbox#9238

[LHBL2003]

I just found your Hidden Gen 10 etc. I have another example here for ProLiant DL380 Gen7.

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02215285

`

manufacturer: HPE model: ProLiant DL380 Gen7 slug: hpe_dl380_gen7 part_number: '' u_height: 2 is_full_depth: true subdevice_role: '' airflow: '' comments: '' console-ports:

• name: Front USB1 type: usb-a label: '' description: ''
• name: Front USB2 type: usb-a label: '' description: ''
• name: Front VGA type: other label: '' description: ''
• name: Rear USB1 type: usb-a label: '' description: ''
• name: Rear USB2 type: usb-a label: '' description: ''
• name: Rear VGA type: other label: '' description: ''
• name: Serial type: de-9 label: '' description: '' interfaces:
• name: Gig-E 1 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 2 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 3 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 4 type: 1000base-t mgmt_only: false label: '' description: ''
• name: iLO type: 1000base-t mgmt_only: true label: '' description: '' module-bays:
• name: PCIe1 label: primary riser position: PCIe1 description: ''
• name: PCIe2 label: primary riser position: PCIe2 description: ''
• name: PCIe3 label: primary riser position: PCIe3 description: ''
• name: PCIe4 label: secondary riser position: PCIe4 description: ''
• name: PCIe5 label: secondary riser position: PCIe5 description: ''
• name: PCIe6 label: secondary riser position: PCIe6 description: ''
• name: PCIe7 label: tertiary riser position: PCIe7 description: ''
• name: PCIe8 label: tertiary riser position: PCIe8 description: ''
• name: PSU1 label: '' position: PSU1 description: ''
• name: PSU2 label: '' position: PSU1 description: '' `

[weidi]

I just found your Hidden Gen 10 etc. I have another example here for ProLiant DL380 Gen7.

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02215285

`

manufacturer: HPE model: ProLiant DL380 Gen7 slug: hpe_dl380_gen7 part_number: '' u_height: 2 is_full_depth: true subdevice_role: '' airflow: '' comments: '' console-ports:

• name: Front USB1 type: usb-a label: '' description: ''
• name: Front USB2 type: usb-a label: '' description: ''
• name: Front VGA type: other label: '' description: ''
• name: Rear USB1 type: usb-a label: '' description: ''
• name: Rear USB2 type: usb-a label: '' description: ''
• name: Rear VGA type: other label: '' description: ''
• name: Serial type: de-9 label: '' description: '' interfaces:
• name: Gig-E 1 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 2 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 3 type: 1000base-t mgmt_only: false label: '' description: ''
• name: Gig-E 4 type: 1000base-t mgmt_only: false label: '' description: ''
• name: iLO type: 1000base-t mgmt_only: true label: '' description: '' module-bays:
• name: PCIe1 label: primary riser position: PCIe1 description: ''
• name: PCIe2 label: primary riser position: PCIe2 description: ''
• name: PCIe3 label: primary riser position: PCIe3 description: ''
• name: PCIe4 label: secondary riser position: PCIe4 description: ''
• name: PCIe5 label: secondary riser position: PCIe5 description: ''
• name: PCIe6 label: secondary riser position: PCIe6 description: ''
• name: PCIe7 label: tertiary riser position: PCIe7 description: ''
• name: PCIe8 label: tertiary riser position: PCIe8 description: ''
• name: PSU1 label: '' position: PSU1 description: ''
• name: PSU2 label: '' position: PSU1 description: '' `

Hi, might you please post this in the code quotes so it gets formated properly? Right now there is a discussion ongoing wheter to have PCIe and PSUs as modules and as soon this is decided i´m more then happy to include this as well.

[DanSheps]

Please review your implementation and re-adjust, you missed a number of the ports.

Additionally, front/rear port would not be the way to model this.

[github-actions[bot]]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further progress is made.

[weidi]

Is there any plan to merge it? IMHO there are no conflicts any longer.

[bbrk364]

If you look at try using the module is not possible you look at the listing of the disk device or network card or the HBA is a mile long. Then the part number keeps on changing. Server hardware is unlike network equipment because the components of t the OEM keep changing all the time.
Netbox does NOT have a disk drive the type of interface or the size of the HDD as a default data set.

[DanSheps]

If you look at try using the module is not possible you look at the listing of the disk device or network card or the HBA is a mile long. Then the part number keeps on changing. Server hardware is unlike network equipment because the components of t the OEM keep changing all the time. Netbox does NOT have a disk drive the type of interface or the size of the HDD as a default data set.

The same can be said for any data that is hard-coded in NetBox within a server device type. The preferred method for the device-type repository is to model these as modules.

For example, PRs will be rejected for a instance like this where the interfaces are PCI-E cards and it can be easily modelled as a module but were not configured as such. You aren't being asked to add every single PCI-E card in existence, you can add your cards that are in use and then someone else can add theirs. This is the benefit of a modular design.

To contast that, lets say the interfaces were configured as fixed even though they can be in reality be swapped with a different PCI card. You might use a mGig interface while someone else might use SFP+ interfaces. This would mean that after import, they would need to edit the interfaces to change their desired interface type instead of simply swapping the module.

[bbrk364]

W/ server is the PCI card having too many models and the models keep on changing all time. It very hard to maintain an upto dated listing of PCIe for each of the manufacturers. If you look at any server there are a number of interfaces that came as default but you can have the onboard replaced w/ a listing of the optional interfaces. That is why servers have options like 2.5" HDD and 3.5" HDD options and for each HDD size you have option w/ 4 HDD, 8 HDD, 10 HDD, 16 HDD or 24 HDD.

I just try to have the commute to the documentation of the servers Infrastructure w/ netbox