devops on Andrés Álvarez

Useful Zendmd Tricks

Tue, 14 Feb 2017 00:00:00 +0000

The Zenoss Zendmd Tips Wiki page contains a few useful tricks using zendmd to perform tasks. In this post I am adding more tricks that I discover and learn along the way.

Removing Device Classes

We can easily remove device classes within zendmd with a simple command. Assuming we want to remove the default “KVM” device class:

dmd.Devices.manage_deleteOrganizer("/zport/dmd/Devices/KVM")
commit()

Change Zenoss User's Password

Let's say we want to change the default admin user's password (zenoss) in the Ubuntu auto deploy:

app.acl_users.userManager.updateUserPassword('admin', 'newpassword')
commit()

Getting Started With Juju Locally

Fri, 10 Feb 2017 00:00:00 +0000

Juju is a great tool that allows us to deploy many services in a local or cloud environment. Services are deployed into virtual containers and can be removed and re-deployed at any time. It is perfect for creating sandbox and test environments for specific kind of services that you develop for.

In this post I will explain how easy it is to get started with Juju in a local environment.

Installation

To start we will need to add the necessary repository from where we will retrieve the Juju packages:

sudo add-apt-repository ppa:juju/stable
sudo apt-get update

Next we will download and install the Juju core package and the package for local deployment:

sudo apt-get install juju-core
sudo apt-get install juju-local

Setting Up the Local Environment

Before we set up the local environment, let's first generate a configuration file. This file will contain the configuration for many kinds of environments (OpenStack, AWS, MaaS, etc.), including a local environment configuration. We will generate the file and then switch to the local environment:

juju generate-config
juju switch local

Once we have switched to the local environment, we can simply bootstrap the environment with the following command:

juju bootstrap

After the process is complete, we are now ready to start using Juju.

Creating Zenoss ZenPack Daemons

Mon, 07 Nov 2016 00:00:00 +0000

ZenPacks are powerful custom add-ons that can help us extend Zenoss's functionality. In this post I will go over on how to create a ZenPack that adds a custom daemon to the existing Zenoss daemons and runs on a configured cycle time to perform custom tasks. We will achieve this by creating the ZenPack using zenpacklib, but it is also possible to create it from the Zenoss user interface.

About zenpacklib

zenpacklib is a Python library developed by the Zenoss team to facilitate the process of creating ZenPacks, specially ZenPacks that deal with modeling and monitoring devices and components. Most of the newer ZenPacks that are being released are now being built with zenpacklib.

We can obtain zenpacklib by running the following commands:

wget http://zenpacklib.zenoss.com/zenpacklib.py
chmod 755 zenpacklib.py

This will download the zenpacklib Python library and give it executable permissions.

Creating the ZenPack

Using the zenpacklib file we just downloaded, we proceed to create a new fresh ZenPack:

./zenpacklib.py create ZenPacks.<your_namespace>.<zenpack_name>

This will create the ZenPack base directory with the necessary base files.

Now we go into this directory to begin.

cd ZenPacks.<your_namespace>.<zenpack_name>

Creating the ZenPack Daemon

Our custom daemon declaration will be located in a directory named daemons, inside our ZenPack directory:

mkdir ZenPacks.<your_namespace>.<zenpack_name>/<your_namespace>/<zenpack_name>/daemons

Here we will create a new Bashscript file with the name of our daemon. In this case we will name it mydaemon:

#! /usr/bin/env bash

DAEMON_NAME="mydaemon"

. $ZENHOME/bin/zenfunctions

MYPATH=`python -c "import os.path; print os.path.realpath('$0')"` THISDIR=`dirname $MYPATH` PRGHOME=`dirname $THISDIR` PRGNAME=$DAEMON_NAME.py CFGFILE=$CFGDIR/$DAEMON_NAME.conf

generic "$@"

Once the ZenPack is installed, files under this daemons directory will become executable (chmod 0755), a symlink to the file will be created in $ZENHOME/bin, and a configuration file will be generated in $ZENHOME/etc/<daemon_name>.conf

NOTE: If you created your ZenPack using the Zenoss user interface, the daemons directory will also be automatically created, and will contain an example daemon file named zenexample with code similar to the one above. In this case you should simply replace the necessary values.

Monitoring CPU Utilization in Zenoss

Fri, 04 Nov 2016 00:00:00 +0000

While taking a look at the CPU Utilization graphs offered Zenoss Core's Linux Monitor ZenPack (v1.2.1), I noticed that the percentage values for Idle were ridiculously high:

This made sense since this particular device contains 16 cores. However, this then means that the monitoring template isn't really taking this into consideration, and instead just spits out the total value from all cores.

Triggering Commands From Events in Zenoss

Mon, 31 Oct 2016 00:00:00 +0000

In Zenoss Core 4, we can configure some email notifications that produce and send emails based on conditions defined in a trigger, when an event is created.

Additionally, Zenoss Core 4 also provides command type notifications that allow us to execute commands in the Zenoss machine when the trigger criterias are met.

For example, let's say we want to execute a script everytime we ping a device and get no response. This scenario would involve the following:

The device is suddenly down.
Zenoss pings the device and gets no response.
The device status is then changed to DOWN.
An Event with an event class of /Status/Ping and a severity of Critical is created.

With this information, we can create a trigger that will represent this exact scenario. Moreover, we can configure a command notification to be executed when this trigger is fired.

Configuring a Trigger

Navigate to Events > Triggers
Create a new trigger.
Add the rules that represent the scenario mentioned before. In this case, all of these rules must apply:

=> Because we want to make sure the device is truly DOWN, and has been so for quite a while, we also want to add a condition that checks that the event count is greater than a certain number, only then the trigger will be fired, and consequently, the command.

Keystone Interface in Juju Charms

Fri, 28 Oct 2016 00:00:00 +0000

Juju Charms interfaces make possible the interaction and exchange of data between services deployed by Juju. In this post I will explain how we can use the Keystone interface to make our custom charm service comunicate with the Keystone service within a Juju environment.

In the end, what we really want to achieve, is to link both services so that they can exchange data, using a Juju command:

juju add-relation keystone myservice

Juju Relations

Juju relations operate behind the concept that one service provides something, while another service requires it, and the interaction between the services is done through an interface. Since we want to interact with Keystone, this means that we need to use a suitable keystone interface that allows us to get what we need, the keystone Identity data. For this, we use the keystone-admin interface.

With this in mind, we configure our charm to require this relation and interface in metadata.yaml:

# ...
requires:
  identity-admin:
    interface: keystone-admin