Enable `PatchPanel` to be visible in Racks/Enclosures graphical view
Closed this issue ยท 2 comments
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
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
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!