Developing Zenoss in the Control Plane

Since serviced runs Zenoss services from an image, development of Zenoss per se would typically mean making changes, committing them to an image, then restarting the services to pick up the new image. zendev simplifies this process by creating a lightweight image that mounts Zenoss source from your host filesystem.

Building the Image

First step is to create the image, zendev/devimg. You may choose to build an image that includes any ZenPacks available in your source tree; there is a shortcut option to build a straight Resource Manager image.

# Make sure you have necessary repos (first time only)
zendev restore develop

# Build Core image
zendev build devimg

# Build Core image + a couple zenpacks
zendev build devimg -p EnterpriseCollector -p DistributedCollector

# Build Resource Manager image
zendev build devimg --resmgr
The image this creates has:
  • Your zendev source root mounted at /mnt/src
  • Your zendev zenhome mounted at /opt/zenoss
  • A full Zenoss source build run
  • ZenPacks installed (ZenJMX and PythonCollector + whatever you specified)
  • $(zendev root)/src/core/Products symlinked to /opt/zenoss/Products
  • A zenoss user with the same GID/UID as your current user, so you don’t have permission problems with the mounted source (sudoer, NOPASSWD)

For the most part, since ZENHOME, SRCROOT, GOPATH, etc. are all the same on the host as in the image, you should be able to run make; make install for a component on your host, or edit source in Products directly, and have it all work out so that the image serviced uses gets those changes without having to do any image rebuilding.

Running Control Plane

Once your image exists, you can start the control plane using zendev serviced (this replaces zendev resetserviced).

usage: zendev serviced [-h] [-r] [-d] [-a] [-x] [--template TEMPLATE]
                       [--no-auto-assign-ips] [-u UIPORT] [-- ARG [ARG...]]

optional arguments:
  -h, --help            show this help message and exit
  -r, --root            Run serviced as root (DEPRECATED. Currently ignored;
                        see --no-root)
  -d, --deploy          Add Zenoss service definitions and deploy an instance
  -a, --startall        Start all services once deployed

  -x, --reset           Clean service state and kill running containers first
  --template            {Zenoss.core,Zenoss.core.full,Zenoss.resmgr.lite,Zenoss.resmgr}
                        Zenoss service template directory to compile and add
  --no-root             Don't run serviced as root
  --no-auto-assign-ips  Do NOT auto-assign IP addresses to services requiring
                        an IP address
  -u UIPORT, --uiport UIPORT
                        UI port (default 443)

Any arguments beyond the standard -- will not be parsed by zendev, and will instead be passed directly to serviced.

Note: if you use --template to deploy a Zenoss.resmgr template, you must previously have built the devimg with the necessary ZenPacks installed.

Now you can make any changes you want to the source on your host, then bounce the service in the control plane UI or CLI to have your changes take effect.

Attaching to Running Containers: zendev attach

There’s a simple wrapper for nsinit called zendev attach which uses serviced attach. For example, to drop into bash on the container running Zope, run:

zendev attach zopectl