Enable `PatchPanel` to be visible in Racks/Enclosures graphical view

[Molkobain]

Hi Christophe,

First of all, thanks for this great extension and for making a bridge module to Datacenter View Extended! 🙌

Symptom

I've got feedback from some users of both extensions reporting that PatchPanel objects were not displayed in Racks/Enclosures graphical view by default.

Cause

Although the necessary DM attributes and methods are presents on the PatchPanel class, it is not enabled in the custom_device_classes module parameter (see here)

Workaround

They can add the class to the module parameter manually.

Example

'molkobain-datacenter-view-extended' => array (
    'custom_device_classes' => ['PatchPanel'],
),

Solution

I was about to make a PR for this, but then the way to actually do it wasn't that obvious and I would like to know how you would prefer it to be done.

Option 1

Convert module parameters of DVE to XML module parameters

Pros

• You could add PatchPanel as an XML delta.

Cons

• Doesn't seem like a good idea as the param. is already written in the conf. file of all users.
• Would not work for any user who already overloaded the param. in their conf. file.

Option 2

Use the \ModuleInstallerAPI::BeforeWritingConfig(Config $oConfiguration) API to add the value to the existing values.

Pros

• Would work for everybody, including those using existing version of DVE

Cons

• We don't have the version numbers of the module being installed, therefore we can't alter the parameter only once, it will be done at each setup, which can be an issue (?) or at least isn't very clean. But, it is done by Combdo here 😁

Option 3

Use the \ModuleInstallerAPI::BeforeDatabaseCreation(Config $oConfiguration, $sPreviousVersion, $sCurrentVersion) API to add the value to the existing values.

Pros

• Would work for everybody, including those using existing version of DVE
• Could be done only once when installing the new module version

Cons

• That API is not made for this, not sure it would work in the future. Plus, it never feels good to "hack" an API for something out of its scope.

Questions

• Which option suits you the best? Or do you have a better option?
• Would you consider a PR for this?

Take care, Guillaume

[xtophe38]

Hello Molkobain,

Option 2 would probably be the less painful.

However, since multiple extensions may create physical classes that don't derive from PhysicalDevices, it would be good to have a scalable process to allow these classes to be displayed in racks. I see 2 other options to answer that need. For each of them, the idea is that BVE itself automatically detects what can be displayed in its racks or not.

Option 4

You request that these classes provide a method that tells if the class is elligible to be set in a rack or not. By default, it is not.

Pros

• Easy to implement
• No modification of the config file needed

Cons

• You need to trust the extension
• The extensions need to carrefully make sure your requirements don't evolve

But well, this is already the case with the 3 first options.

Option 5

You write a piece of code that scan the datamodel to detect the classes that can be racked and for each of these classes, you make sure that all required conditions are met.

Pros

• Scalable
• Automatic
• No modification of the config file needed

Cons

• I don't see any beside the fact that it will require you some work

Note that TeemIp already does something similar to list the objects which classes carry external keys to IP addresses. This is used to propose meaning full devices to users who want to attach a CI to a given IP

What do you think ?

Cheers, Christophe

[Molkobain]

That's actually a very good idea, I should have thought of it, sorry. It's a shame we can't use PHP interfaces in the XML datamodel, otherwise it would have been perfect and I could have use the native mechanism. Instead I'll check for a specific method like you suggested and cache it.

Thanks!