Keystone Interface in Juju Charms

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
juju keystone devops bash keystone openstack

Zenoss Renderers

Zenoss makes use of some very interesting graphical components called renderers. These are used to manipulate the way data is shown in the Zenoss user interface.

For example, a value of total bytes used could be 6080626688 in bytes, which is a very high number and doesn't really convey much meaning. However, we can use a built-in Zenoss renderer called bytesString which will convert this value in bytes to the closest representation:

Zenoss Renderers

As we can see, this is a much better and meaningful way of displaying the data.

The built-in Zenoss renderers and source code can be found in $ZENHOME/Products/ZenUI3/browser/resources/js/zenoss/Renderers.js

They are a list of registered Javascript functions that can be assigned in our YAML definitions file by adding the renderer property. For example:

HardDisk:
  base: [zenpacklib.Component]
  label: Hard Disk
  properties:
     location:
        label: Location

     capacity:
        label: Capacity

     raid_name:
        label: Raid Name

     raid_level:
        label: Raid Level

     status:
        label: Status
        renderer: Zenoss.render.pingStatus

Zenoss.render.pingStatus is one of the default renderers that come built-in within Zenoss Core 4, similar to Zenoss.render.bytesString.

zenoss zenpacks

Configuring a local apt repository

Setting up a local apt repository can allow you to use apt-get install command to install your own packages. This is a better approach than using dpkg -i because apt will fetch and install the required dependencies (which should also be located in your local repository) in an offline fashion.

Add Local Repository to Sources

First we need to add our local repository to apt's list of source repositories, this can be found in /etc/apt/sources.list. To add our local repository, we add the following line at the top of the file:

/path/to/local-deb-repo/ ./

Where local-deb-repo is the name of our local repository directory.

Add Debian Packages

Now we create local repository's directory just like we specified it in the previous step:

mkdir /path/to/local-deb-repo/

Once we've done that, we can proceed to put the Debian package files (.deb) and their dependencies inside the directory.

linux apt aptitude repository

Managing Debian Package Dependencies

In a previous post, I talked about building a simple Debian package in Ubuntu, however I did not go into details on how to manage the dependencies that your Debian package might require. In this post I will cover exactly that.

dpkg and Dependencies

Previously we installed our package using the dpkg -i command. However, the problem with dpkg is that by itself, it is not capable of managing repositories. Therefore, higher level tools (such as apt-get) are required to fetch dependencies from repositories.

dkpg is only the core tool that installs/removes/configures packages, taking care of dependencies and other factors. apt-get and aptitude are tools that manage repositories, download data from them, and use dkpg to install/remove packages from them. This means, that apt-get and aptitude can resolve dependencies and get required packages from repository, but dpkg cannot, because it knows nothing about repositories.

linux ubuntu debian packaging
← Newer Posts Older Posts →