You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the new inventory_config we have seen, that implementing a new resourcekind leads to adding all the respective functions in our code. Let's take vcops as an example.
That scheme goes on for every new adapter, currently for our two additional adapters, sddc and vcops.
We need to make that generic and have the adapterkind specified in inventory_config. Instead of the specific implementation we need to run through generic functions which would take the content of the config file instead to specify the needed adapterkind.
At least these two adapters should be reworked that way.
TBD:
When we have that as a first step, we should consider reworking vcenter_objects and nsxt_objects too. The hard lock in for nsx-t might not fit every use case others may have, just because we are using it. Now that we have the possibility to externally configure this kind of stuff, we should outsource it too. However, the implementation of the latter is different and needs some more love before that's possible.
The text was updated successfully, but these errors were encountered:
With the new inventory_config we have seen, that implementing a new resourcekind leads to adding all the respective functions in our code. Let's take
vcops
as an example.The following places need to be adapted:
Config
InventoryBuilder 1
InventoryBuilder 2permanent query
InventoryBuilder 3
Vrops.py
That scheme goes on for every new adapter, currently for our two additional adapters,
sddc
andvcops
.We need to make that generic and have the
adapterkind
specified ininventory_config
. Instead of the specific implementation we need to run through generic functions which would take the content of the config file instead to specify the neededadapterkind
.At least these two adapters should be reworked that way.
TBD:
When we have that as a first step, we should consider reworking
vcenter_objects
andnsxt_objects
too. The hard lock in fornsx-t
might not fit every use case others may have, just because we are using it. Now that we have the possibility to externally configure this kind of stuff, we should outsource it too. However, the implementation of the latter is different and needs some more love before that's possible.The text was updated successfully, but these errors were encountered: