What is the typical workflow for developing Zenoss ZenPack?
The development of ZenPack seems to involve the creation of many steady states. There are classes of models that are clearly persistent. There are skins associated with model objects. There are organizers and instances of persistent classes (data sources, graphics, etc.).
Considering that many things get done wrong during development before they get done right, and given that loading a ZenPack that does something wrong has permanent consequences for the Zenoss instance it is loaded into, and that these consequences are difficult to reverse What is the common approach for ZenPack development?
source to share
I don't know anything about Zenoss, but these situations are common to any system that has some form of persistent configuration, such as Zope and Plone.
And the workflow is that you create a test environment that you can delete and copy, but in parts and in general. For example, for a typical Plone site, you have a buildout that allows you to replicate your development environment including all dependencies. Then there is a script / function in the plug-in under development that allows you to customize the persistent configuration as you wish.
As a result, you can easily restore the desired state.
You also have “stages” in your workflow. Development is usually performed on each local development machine. Carrying out / testing which is performed on the test server. This is done by copying the persistent state of the production machines to the staging machine and then running any install / update scripts and ensuring everything works. Finally, you update the production server.
source to share
I have been working on this issue this week with Zenoss 3.1.
Protest - If you do a bad zenpack - don't wait - when you do a bad one it might get stuck in the Zope db and there is no way to get it AFAIK. So that -
Use the GUI first to make a full backup of your clean Zenoss site.
You will need to restore zenrestore later to clean up the clutter.
There are two answers, I think:
1) if its portlet is
Portlets can only be installed using an egg. Usually Zenoss docs recommend that you create eggs using a GUI interface, but this leads to a funny iteration of development. However, the docs have explanations for other ways. If your code, perhaps starting with a familiar community portlet like Show Graph or Google Maps, is fine for portlets rather than regular zenpacks, then
-
you specify the top directory of your code in standard zenpack form, with versions.
-
cd to that directory and run
python setup.py bdist_egg
which will create the dist and build directories.
-
The egg will be in the dist directory.
-
Install the egg using the GUI.
-
Note that it is not fully installed ... grrrrrr.
-
Restart daemons -
zopectl restart ; zenhub restart
-
Test.
-
Delete the portlet using the GUI. Repeat.
Gotchas: - You should have setup.py and possibly one or more INSTALL.txt MANIFEST.in README.txt files in the top directory.
-
Setup.py must match your directory names.
-
If you are using old or copied init .py files with their init .pyc versions , you may need to delete those pyc files in order to force the python script to recreate them.
-
I like to run the script like this just to be sure:
rm -f ./dist ./build ; python setup.py bdist_egg
2) If it's a regular zenpack
The docs tell you how to do this.
-
Get your zenpack installed from any source; often you start with a blank, generated GUI.
-
Copy the files from
/usr/local/zenoss/zenoss/Zenpacks/yourzenpack
into the code development area. -
Disable zenpack using the GUI.
-
From the command line, as a zenoss user, run the zpack install -link command (see the syntax) to install zenpack, which is actually in your code area.
-
Test
-
Update your code.
-
On the command line as zenoss run
zopectl restart ; zenhub restart
-
Test.
- Repeat
... Be happy.
source to share