---

Subject:	My understanding is that
Author:	Jane Curry
Posted:	2015-12-15 15:43

My understanding is that zenpacklib is still the answer. But there is so little relevant documentation on ZenPacks in 5 that it is difficult to progress.

I strongly suggest that development still be done on 4.2.5 and, once developed and tested, move it to 5. So far, I have a reasonbly good success rate this way.

Cheers,

Jane

Email: jane.curry@skills-1st.co.uk    Web: https://www.skills-1st.co.uk

---

Subject:	Thanks for the information.
Author:	Ken Jenkins
Posted:	2015-12-29 14:52

That is our current plan but it is not good to keep two different versions of Zenoss running where we develop on 4.2.5 and move the ZenPacks to 5. It is best to work on like version platforms.

---

Subject:	Totally agree with the
Author:	Jane Curry
Posted:	2015-12-29 16:48

Totally agree with the sentiment but I can't find enough info to sensiby DO the developmemnt on 5 - and the bit I can find says I have to reinstall a ZenPack along with a Zenoss stop , backup and start, in order to make minimal changes. I KNOW in 4 that i don't need such a heavyweight process; in 5 the only info i have is from Zenoss - and it will drive me bonkers to go through that process to tweak one line in a modeler.

Cheers,

Jane

Email: jane.curry@skills-1st.co.uk    Web: https://www.skills-1st.co.uk

---

Subject:	I've just published a revamp
Author:	Chet Luther
Posted:	2016-01-20 13:50

I've just published a revamp of the zenpacklib documentation that is now focused on Zenoss 5 ZenPack development.

http://zenpacklib.zenoss.com/

I recommend starting at the beginning. The "Development Environment" section is going to most useful to those of you who were already developing ZenPacks on Zenoss 4. The rest of the content will be very familiar if you've previously looked at the zenpacklib documentation, or been through the ZenPack development training class.

---

Subject:	Trying to follow the new docs
Author:	Jane Curry
Posted:	2016-01-25 13:47

Trying to follow the new docs.

Working as the zenoss user, I believe setup as per your instructions, on the "outside".

Aliases setup - so I can type "zope" and "zenhub" and get to the correct containers.

I can type zenpack --list and get a list of zenpacks.

I have ZenPacks.community.DirFile in /z/zenpacks where the zenpacks directory is world read/write/execute.

cd /z/zenpacks

zenpack --link --install ZenPacks.community.DirFile

gives

ERROR message ZenPacks.community.DirFile does not appear to be a valid file or directory

serviced service run zope zenpack link ZenPacks.community.DirFile

seems to work

Tested with 2 different ZenPacks and get the same results.

Also, for development, I always do a a ZenPack link install.

This seems to put code into /var/zenoss/ZenPackSource. Once code is in there, you can't just repeat the link command above as it says the code "already exists, cannot cop zenpack".

The only method I have found to resolve this is:

serviced service shell -s BlowZp -i zope bash

cd /var/zenoss/ZenPackSource

rm -rf

check whether the install has got far enough to put a link in /var/zenoss/ZenPacks - if there is an egg-link, remove that too.

Exit the container

serviced snapshot commit BlowZp

... and you can't reuse your "BlowZp".

Is this really the method I have to use for a link install

Cheers,

Jane

Email: jane.curry@skills-1st.co.uk    Web: https://www.skills-1st.co.uk

---

Subject:	Ken,
Author:	Chet Luther
Posted:	2016-01-25 20:04

Ken,

Currently we don't have any hard plans to convert a MIB into a zenpack.yaml, or a subset of a zenpack.yaml. Though I've heard it come up a couple times before from others.

It seems like there are a couple of things that could be autogenerated. Monitoring templates for scalar (non-indexed) integers and counters, and creation of components, relationships and per-component monitoring templates for indexed integers and counters. This would at least provide a copious amount pre-configuration that would likely have to be whittled down to what would actually be useful. I know that a lot of MIBs I've seen don't exactly align with devices' real capabilities.

I don't think there's anything useful that could be done for traps. Just importing the MIB so the various OIDs in the traps can be decoded can already be done.