Upgrading a Zenoss 5.1.x development environment

I have a development environment specifically used for developing ZenPacks - Zenoss 5.1.5 with Control Center 1.1.7. This is a Core environment.

I create and test ZenPacks using guidance from Chet about 5.x development environment - see http://zenpacklib.zenoss.com/en/latest/development-environment-5.html . Basically /z is shared between the base host and all containers; ZenPack development code goes under /z/zenpacks and I work with aliases provided in the article above so that, from the base host, I can run zenpack --link --install - just as I always did in Zenoss 4. All works fine. Toolbox tools run clean.

Wanted to upgrade to Control Center 1.1.9 and Zenoss 5.1.8. Use the latest Upgrade Guide from the docs site.

CC is relatively smooth. Document not totally clear that you do need to modify /etc/default/serviced with an amalgamation of the newly supplied serviced.rpmnew and your original serviced. I also found that my original had a line with SERVICED_DM_THINPOOLDEV=/dev/mapper/serviced-serviced--pool - and I needed to put that in - didn't exist at all in the rpmnew file.

Big problems with upgrading Zenoss. It barfs on all my link-installed ZenPacks and the install finally gives up and abandons. I repeat - this is a ZenPack development environment - it's raison d'etre is to have link-installed ZenPacks.

If you attach to the zope container as root, there is a /root/5.1.x directory, which amongst other files, has upgrade-core-5.1.x.sh and upgrade-core.txt. The .txt file appears to be the steps to run with the last one being:

SVC_RUN "Zenoss.core/Zenoss/User Interface/Zope" upgrade

This txt file is run from the upgrade-core-5.1.x.sh file which runs:

serviced script run /root/5.1.x/upgrade-core.txt --service Zenoss.core

The fundamental problem is that my ZenPacks need access to my shared /z/zenpacks directory but the upgrade script doesn't have /z mounted. Thus the existing link-installed ZenPacks are all "broken". Worse still, the shellscript has "serviced script run..."; serviced script cannot take a mount parameter; serviced service run can, but serviced script run cannot.

The way I finally kludged this was to comment out the "SVC_RUN "Zenoss.core/Zenoss/User Interface/Zope" upgrade" line in the txt file and then manually run:

serviced service run --mount /z,/z edvpiw0k718inm2qrpdmhp5as upgrade

where the weird id above is the container id for your Zope container. This takes the --mount /z,/z making my shared directory hierarchy with ZenPacks, available to the upgrade process. Don't forget to manually run the last line of the shellscript file - /opt/serviced/bin/serviced-set-version Zenoss.core 5.1.8.

There has to be a better way than this! Also, if you need to run the upgrade, you will need to remove the snapshot that is taken as it has a fixed tag name of preupgrade-core-5.1.8. The process is documented in chapter 4 of the upgrade guide.

Some of my Zenoss configuration has survived the upgrade; other hasn't. Most of the ZenPacks are fine and work, with the exception of one reporting ZenPack.

Things that get lost are:

Any operating system utilities you have installed in containers

Any modifications to any code under /opt/zenoss/Products - I have a few tweaks I need to circumnavigate bugs.

Any modifications in /opt/zenoss/bin get lost. I have a ZenPack that installs a daemon which needs files in /opt/zenoss/bin and in /opt/zenoss/Products/ZenRRD. Had to manually copy them in the original install; had to recopy them again after upgrade.

Toolbox tools live under /opt/zenoss/bin so that has to be reinstalled!

Things that survive are:

Customisation for the zenoss user in containers - .ssh files, .vim files,..

General configuration all looks OK - conf files in /opt/zenoss/etc are all preserved as are SMTP setting and Googlemaps API keys.

Installed MIBs, Event classes and transforms all look OK.

There may be a better way of going about this. If so, please can someone point me at the documentation.

I am hoping by giving this amount of detail, that:

a) Someone will annotate it with better procedures

b) Anyone else going down this route doesn't have to spend quite so long on it

Cheers,

Jane

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