Problem 1:
RRD template exporting and importing was disabled (prematurely, for
reasons which will become obvious below) in favor of the incomplete ZenPack
mechanism.
This meant that even if the underlying object structure was OK, it's impossible
to import Zenoss 1.1.x templates into a clean 2.x install; the only automated
way is through an in-place upgrade.
Problem 2:
Zenoss (up through 2.0.6) can't export a correctly-formed zenpack, so they
can't be imported on another system. It doesn't correctly recursively zip
up all the directories under the zenpack's Product directory.
I found that I could work around this by manually zipping up my own zenpack and
ignoring the exported zip archive.
Problem 3:
Once "added" to a zenpack, and object is really bound to/
contained by that zenpack, and if you remove that zenpack you destroy
all of the objects that are now contained in that zenpack. There is
no documented revert procedure.
Example: experimenting with using zenpacks to transport zProperties to
multiple zenoss servers, I added the /dmd/Devices object to a zenpack.
I installed this on a test instance, and it seemed to set the properties
as I expected. But then when I deleted that ZenPack from the test system,
it *completely* stripped the test instance of *all* sub-organizers below
/dmd/Devices.
I need to maintain parallelism between 20 zenoss servers in five sites
across the world. ZenPacks have been a giant step backwards in managability.
I'm still a fan, but this kind of stuff is causing $management to continue
to ask me whether I made the right choice.
--
David Carmean Network Appliance, Inc
Infosystems Architect, 495 E. Java Drive
Java (Sunnyvale) Engineering Lab Services Sunnyvale, CA 94089
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
