Zenoss ZenPack 开发的典型工作流程是什么？
ZenPack 开发似乎涉及各种持久状态的创建。有一些模型类明确表示持久状态。有一些与模型对象关联的皮肤。有持久类的组织者和实例（数据源、图表等）。
考虑到在开发过程中，很多事情在做对之前都会做错，并且考虑到加载做错事情的 ZenPack 会对加载到的 Zenoss 实例产生持久的后果，并且这些后果很难撤销，什么是ZenPack 开发的常用方法是什么？
ZenPack development seems to involve the creation of a variety of persistent state. There are model classes which represent explicitly persistent state. There are skins which are associated with model objects. There are organizers and instances of persistent classes (data sources, graphs, etc).
Considering that during development, many things are done wrong before they're done right, and considering that loading up a ZenPack that does things wrong has persistent consequences on the Zenoss instance it is loaded into and that these consequences are hard to undo, what is the usual approach for development of a ZenPack?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对 Zenoss 具体一无所知，但这种情况对于任何以一种或另一种形式具有持久配置的系统都很常见，例如 Zope 和 Plone。
工作流程是创建一个可以删除和复制的测试环境，但可以部分或全部删除和复制。例如，对于典型的 Plone 站点，您有一个 buildout 可以让您复制开发环境，包括所有依赖项。然后，在您开发的扩展模块中，您有一个脚本/函数，允许您根据需要设置持久配置。
这使您能够轻松地重新创建所需的状态。
您还有工作流程“阶段”。开发，通常在每个开发人员的本地计算机上完成。登台/测试，在测试服务器上完成。这是通过将生产计算机的持久状态复制到登台计算机，然后运行任何设置/升级脚本并确保一切正常来完成的。最后升级生产服务器。
I don't know anything about Zenoss specifically, but this situations are common for any syste that have persistent configuration in one form or another, like Zope and Plone for example.
And the workflow is that you create a test environment that you can delete and replicate, but in parts and in whole. For a typical Plone site, for example, you have a buildout that lets you replicate the development environment including all dependencies. Then in the extension module you develop you have a script/function that allows you to set up the persistent configuration as you want it.
This results in you being able to easily recreate a desired state.
You also have workflow "stages". Development, typically done on each developers local machine. Staging/testing, which is done on a test server. This is done by copying over the production machines persistent state to the staging machine, and then running any setup/upgrade scripts, and making sure everything works. Finally you the upgrade the production server.
本周我正在使用 Zenoss 3.1 解决这个问题。
警告-
如果你制作了一个糟糕的 zenpack - 不等 - 当你制作了一个糟糕的 zenpack，它可能会卡在 Zope 的数据库中，而且据我所知，没有办法将其取出。所以
- 首先使用 GUI 对干净的 Zenoss 站点进行完整备份。
稍后您将需要使用 zenrestore 进行恢复以清理混乱。
我认为有两个答案：
1) 如果它是一个 portlet-
Portlet 只能使用 Egg 来安装。通常，Zenoss 文档建议您使用 GUI 界面创建 Egg，但这会导致荒谬的开发迭代。不过文档中也有其他方式的解释。如果您的代码（可能以 Show Graph 或 Google Maps 等知名社区 portlet 开头）对于 portlet 而不是常规 zenpack 来说是正确的，那么
您可以以标准 zenpack 形式命名代码的顶级目录，
与版本。
cd 进入该目录并运行
python setup.py bdist_egg这将创建 dist 和 build 目录。
egg 将位于 dist 目录中。
使用 GUI 安装 Egg。
注意它没有完全安装... grrrrrr。
重新启动守护进程 -
zopectl restart ; zenhub restart测试。测试
使用 GUI 删除 portlet。重复。
陷阱：
- 您必须在顶级目录中拥有 setup.py 以及 README.txt 中的 INSTALL.txt MANIFEST.in 中的一个或多个。
Setup.py 必须与您的目录名称匹配。
如果您使用旧的或复制的 init.py 文件及其 init.pyc 版本，那么您可能需要删除这些 pyc 文件以强制 python 脚本重新创建它们。
为了确定起见，我喜欢按如下方式运行脚本：
rm -f ./dist ./build ; python setup.py bdist_egg
2) 如果它是常规的 zenpack
文档告诉您如何执行此操作。
从任何来源安装你的 zenpack；通常你会从 GUI 创建的空包开始。
将文件从
/usr/local/zenoss/zenoss/Zenpacks/yourzenpack复制到您的代码开发区域。使用 GUI 卸载 zenpack。
在命令行上以 zenoss 用户身份运行 zpack install --link 命令（查找语法）以安装实际位于代码区域中的 zenpack。
测试
更新您的代码。
在 zenoss 命令行上，运行
zopectl restart ； zenhub restart测试。
重复。保持快乐。
I am working on this very problem this week with Zenoss 3.1.
Caveat-
If you make a bad zenpack - no wait - when you make a bad one, it can get stuck in Zope's db, and there is no way to get it out AFAIK. So-
First use the GUI to make a complete backup of a clean Zenoss site.
Later you will need to restore using zenrestore to clean up the mess.
There are two answers, I think:
1) if its a portlet-
Portlets can only be installed using an egg. Normally Zenoss docs recommend you create eggs using the GUI interface, but that makes for a ridiculous development iteration. However there are explanations in the docs of other ways. If your code, possibly starting with a well-know community portlet like Show Graph or Google Maps, is correct for portlets as opposed to regular zenpacks, then
you name the top directory of your code in the standard zenpack form,
with versions.
cd into that directory and run
python setup.py bdist_eggwhich will create dist and build directories.
The egg will be in the dist directory.
Install the egg using the GUI.
Notice its not fully installed... grrrrrr.
Restart the daemons -
zopectl restart ; zenhub restartTest.
Delete the portlet using the GUI. Repeat.
Gotchas:
- You must have setup.py and maybe one or more of- INSTALL.txt MANIFEST.in README.txt 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, then you may need to delete these pyc files to force the python script to re-create them.
I like to run the script as follows just to be certain:
rm -f ./dist ./build ; python setup.py bdist_egg2) If it's a regular zenpack
The docs tell you how to do this.
Get your zenpack installed from whatever source; often you will just start with the empty one created by the GUI.
Copy the files from
/usr/local/zenoss/zenoss/Zenpacks/yourzenpackinto your code development area.Un-install the zenpack using the GUI.
On the command line as zenoss user, run the zpack install --link command ( look up syntax) to install the zenpack thats actually in your code area.
Test
Update your code.
On the command line as zenoss, run
zopectl restart ; zenhub restartTest.
Repeat. Be Happy.