mbruzek

# The machine constraints for each service in this bundle
# have been commented out so you don't run into quota
# problems on public clouds. Modify and uncomment the
# constraints: lines for each service to reflect your
# deployment before moving to production.
#
series: xenial
applications:
  filebeat:
    charm: "cs:filebeat-5"

mbruzek

!!!Note: This is an important note. How does it get rendered in Github flavored markdown?

Hello this is a quote block using the > sign.

mbruzek

Here are some of the tips and trick I have learned when writing reactive charms. I have attached a simple bash example that helps illustrate the points in this email.

@hook decorators:

You almost never need @hook if you structure the reactive states correctly. I always have an "entry point" or a function that is called when no states are set (install_db2 in this example), and the function always sets the state when completing successfully. This function could be equivalent to the install hook, but is much better because removing the "[name].installed" state will cause the software to install again on the next reactive event cycle, where the install hook is only called on deploy and upgrade.

Immutability:

I normally have an "final state" that is always set when everything is complete. The reactive framework evaluates all the when and when_not decorators each time the states change, or a hook is run. So my "final state" function acts as a config-changed hook because the code will be run every time the react

mbruzek

series: trusty
services:
  elasticsearch:
    charm: "cs:~lazypower/development/trusty/elasticsearch"
    num_units: 1
    options:
      "apt-repository": "deb http://packages.elastic.co/elasticsearch/2.x/debian stable main"
      "firewall_enabled": false
  logstash:
    charm: "local:trusty/logstash"

mbruzek

relation-get

relation-get reads the settings of the local unit, or of any remote unit, in a given relation (set with -r, defaulting to the current relation identifier, as in relation-set). The first argument specifies the settings key, and the second the remote unit, which may be omitted if a default is available (that is, when running a relation hook other than -broken).

If the first argument is omitted, a dictionary of all current keys and values will be printed; all values are always plain strings without any

mbruzek

leader-set

leader-set immediately writes the key/value pairs to the state server, which will then inform non-leader units of the change. It will fail if called without arguments, or if called by a unit that is not currently service leader.

leader-set acts much like relation-set, in that it lets you write string key/value pairs (in which an empty value removes the key), but with the following differences:

mbruzek

package main

import (
	"fmt"
	"io/ioutil"
	"log"
	"math/rand"
	"net/http"
	"net/url"
	"os"

mbruzek

This is a follow up to the original Juju pull request: kubernetes/kubernetes#5414

On @erictune's suggestion we are adding the charms and a bundle to keep in better sync with the kubernetes project.

cluster/kube-up.sh will deploy the local charms and the bundle from the kubernetes repository and stand up a cluster.

We have done a lot of work to update the cluster/juju/util.sh to the v0.15.0 release that changed the API and a lot of things.

• Added the Juju charms to cluster/juju/charms directory.

mbruzek

kubernetes-cluster:
  services:
    "kubernetes-master":
      charm: cs:~kubernetes/trusty/kubernetes-master-5
      annotations:
        "gui-x": "600"
        "gui-y": "0"
      expose: true
    docker:
      charm: cs:trusty/docker-2

mbruzek

#!/bin/bash
set -eux
# This script collects all the charms we are trying to get running on power.

# Theh first parameter is the base directory destination.
if [ -d "$1" ]; then
  cd $1
fi

# Power only supports trusty.