zenoss / ZenPacks.zenoss.ZenPackLib

This is a helper library for zenpacks.
http://zenpacklib.zenoss.com/
GNU General Public License v2.0
15 stars 17 forks source link

ZPS-8777: when not installing ZP, don't load yaml files that are only… #575

Closed StevePC closed 9 months ago

StevePC commented 9 months ago

… needed at install time

joshw commented 9 months ago

I generally like the idea behind this change, but I think it would break something I have been planning to merge (https://github.com/zenoss/zenoss-prodbin/commit/08dc609261fe9f3823bb75f1717cfddda760f8fa#diff-69550b8b649cc02b3f01c385454d956839461dbf9d8543953c6f03a67e2307f2R111) - basically, I want to figure out what zenpack "owns" a device, and part of that involves looking at the device classes that contain it to see what zenpack created them. Right now, for ZPL zenpacks, that means looking at pack.device_classes, which i think your change might cause to be unpopulated. It doesn't seem simple to work around this either.

StevePC commented 9 months ago

I generally like the idea behind this change, but I think it would break something I have been planning to merge (zenoss/zenoss-prodbin@08dc609#diff-69550b8b649cc02b3f01c385454d956839461dbf9d8543953c6f03a67e2307f2R111) - basically, I want to figure out what zenpack "owns" a device, and part of that involves looking at the device classes that contain it to see what zenpack created them. Right now, for ZPL zenpacks, that means looking at pack.device_classes, which i think your change might cause to be unpopulated. It doesn't seem simple to work around this either.

Typically we've looked at the class of the device and traced that back to the zenpack, which should always be there. In reality, since the customer can create deviceclasses and add any kind of device to them, trying to trace device ownership by deviceclass doesn't make much sense.