redis #4

Supports: xenial bionic
Add to new model


Redis is a key-value database in a similar vein to memcache but the
dataset is non-volatile. Redis additionally provides native support
for atomically manipulating and querying data structures such as lists
and sets. The dataset is stored entirely in memory and periodically
flushed to disk.

Snap layer

The Snap layer for Juju enables layered charms to more easily deal with
snap packages in a simple and efficient manner. It provides consistent
configuration for users, allowing them the choice of pulling snaps
from the main snap store, or uploading them as Juju resources for deploys
in environments with limited network access.


To have the Snap layer install snaps automatically, declare the snaps in

  - layer:basic
  - layer:snap
      channel: stable
      devmode: false
      jailmode: false
      dangerous: false
      classic: false
      revision: null
        - ["telegraf:system-observe", ":system-observe"]
        - ["telegraf:log-observe", ":log-observe"]

In addition, for Juju 2.0 you should declare Juju resource slots for
the snaps. This allows operators to have snaps distributed from their
Juju controller node rather than the Snap Store, and is necessary for
when your charm is deployed in network restricted environments.

    type: file
    filename: telegraf.snap
    description: Telegraf snap

:no_entry: Charms that need to support Juju 1.25 or earlier cannot
declare the resource entry in metadata.yaml and can only support snap
installs and updates from the Snap Store.

With the Juju resource defined, the operator may deploy your charm
using locally provided snaps instead of the Snap Store:

juju deploy --resource telegraf=telegraf_0_19.snap cs:telegraf

If your charm needs to control installation, update and removal of
snaps itself then do not declare the snaps in layer.yaml. Instead,
use the API provided by the charms.layer.snap Python package.


In the example layer.yaml above, each snap to install is declared as an
entry in the snap layer options mapping. Each of these entries is
itself a mapping, with a number of optional keys. Most of the keys
correspond to snap install command line options.

  • channel (str) - The channel to use instead of stable. Defaults to stable.
    Ignored if the snap is being installed from a Juju resource.
  • classic (bool) - Acknowledge that the snap uses classic confinement and
    will have full system access.
  • devmode (bool) - Install with non-enforcing security.
  • jailmode (bool) - Override a snap's request for non-enforcing security
  • dangerous (bool) - Install the snap even if it is unverified and could
    be dangerous. Implicitly set if the snap is being
    installed from a Juju resource.
  • revision (str) - Install an explicit revision of the snap. Ignored if the
    snap is being installed from a Juju resource.

The other key is connect, which declares the snap connect commands
to run to connect the snap's plugs to suitable slots. Each entry is a
two element list, with the first item being the plug name and the second
the target snap and slot name. The connections are made after all snaps
have been installed, so you do not need to worry about installation

Snap Refresh

By default, the snapd daemon will query the Snap Store four (4)
times per day to process updates for installed snaps. This layer provides
a charm configuration option for authors and operators to control this
refresh frequency.

NOTE: this is a global configuration option and will affect the refresh
time for all snaps installed on a system.

NOTE: requires snapd 2.31 or higher.


## refresh snaps every tuesday
juju config telegraf snapd_refresh="tue"

## refresh snaps at 11pm on the last (5th) friday of the month
juju config telegraf snapd_refresh="fri5,23:00"

## use the system default refresh timer
juju config telegraf snapd_refresh=""

Currently, the snapd refresh timer may be delayed up to one (1) month. This
can be configured using the max option:

## delay snap refreshes as long as possible
juju config telegraf snapd_refresh="max"

For more information on the possible values for snapd_refresh, see the
refresh.timer section in the system options documentation.


If you have defined your snaps in layer.yaml for automatic installation
and updates, there is nothing further to do.


If your charm need to control installation, update and removal of snaps
itself, the following methods are available via the charms.layer.snap

  • install(snapname, **args). Install the snap from the corresponding Juju
    resource (using --dangerous implicitly). If the resource is not
    available, download and install from the Snap Store using the provided
    keyword arguments.

  • refresh(snapname, **args). Update the snap. If the snap was installed
    from a local resource then the resource is checked for updates and the
    snap updated if the snap or arguments have changed. If the snap was
    installed from the Snap Store, snap refresh is run to update the snap.

  • remove(snapname). The snap is removed.

Keyword arguments correspond to the layer.yaml options and snap command line
options. See the snap command line documentation for authorative details on
what these options do:

  • channel (str)
  • classic (boolean)
  • devmode (boolean)
  • jailmode (boolean)
  • dangerous (boolean)
  • revision (str)

Charmstore Publication/Release

The Charm Store does not yet understand that
most resources should be optional and requires them to be uploaded
before publication. The Snap layer supports the common workaround for
this, requiring you to upload an empty (0 bytes in size) as a stand in
for the resource.

charm push $JUJU_REPOSITORY/builds/mycharm cs:~me/mycharm
charm attach cs:~me/mycharm-0 mysnap=empty.snap
charm release cs:~me/mycharm-1 --channel=beta --resource mysnap-0
juju deploy cs:~me/mycharm --channel=beta

:watch: This should no longer be required once
:bug: Issue 103
is dealt with.


This layer is maintained on Launchpad by
Stuart Bishop (

Code is available using git at git+ssh://

Bug reports can be made at

Queries and comments can be made on the Juju mailing list, Juju IRC
channels, or at


(int) Set the number of databases. The default database is DB 0. You can select a different one on a per-connection basis using SELECT <dbid> where dbid is a number between 0 and 'databases'-1.
(string) Specify the Redis server verbosity level. Choices are: - debug (a lot of information, useful for development/testing); - verbose (many rarely useful info, but not a mess like the debug level); - notice (moderately verbose, what you want in production probably); - warning (only very important / critical messages are logged).
(string) Used by the nrpe subordinate charms. A string that will be prepended to instance name to set the host name in nagios. So for instance the hostname would be something like: juju-myservice-0 If you're running multiple environments with the same services in them this allows you to differentiate between them.
(string) A comma-separated list of nagios servicegroups. If left empty, the nagios_context will be used as the servicegroup
(string) Require clients to issue AUTH <PASSWORD> before processing any other commands.
(int) Accept connections on the specified port.
(string) HTTP/HTTPS web proxy for Snappy to use when accessing the snap store.
(string) The address of a Snap Store Proxy to use for snaps e.g.
(string) How often snapd handles updates for installed snaps. The default (an empty string) is 4x per day. Set to "max" to check once per month based on the charm deployment date. You may also set a custom string as described in the 'refresh.timer' section here:
(int) If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence of communication. This is useful to detect dead peers and to take the connection alive from the point of view of network quipment in the middle. The specified value is in seconds.
(int) Close the connection after a client is idle for N seconds (0 to disable).