mbruzek

#!/bin/bash

# This script sets up the requirements for amulet tests.

set -x 

# Check if amulet is installed before adding the stable repository and updating apt-get.
dpkg -s amulet
if [ $? -ne 0 ]; then
    sudo add-apt-repository -y ppa:juju/stable

mbruzek

#!/usr/bin/env python3

# This amulet test deploys the bundles.yaml file in this directory.

import os
import unittest
import yaml
import amulet

seconds_to_wait = 720

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.

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

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

package main

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

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

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

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

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