Skip to content

Spells Spec v2

Jump to bottom
Adam Stokes edited this page Feb 24, 2017 · 9 revisions

SDK

A common set of functions for spell authors to use if they wish.

Proposal

A common sdk directory in the spells registry to be available to all spells:

https://github.com/conjure-up/spells/tree/master/sdk

Custom charm options

Add ability to side-load certain charm option customizations to the charmstore bundles. This is a way for a spell author to utilize the charmstore bundle but then make certain changes to charms for the provider(s) they want to deploy to. For example, OpenStack spell under localhost provider may want to disable the block devices the LXD charm can write to.

Proposal

A bundle-custom.yaml file to reside in the spells top-level directory. An example:

services:
  lxd:
    options:
       block-devices: None

This will override the LXD options in the openstack-lxd bundle: https://api.jujucharms.com/charmstore/v5/~openstack-charmers/openstack-lxd/archive/bundle.yaml

Pre deploy

A pre deployment script tends to be something that needs to edit some particular config like a LXD profile prior to deploying the applications.

Proposal

A basic shell script that does a sed replace.

#!/bin/bash

set -eu

# Path to executing script
SCRIPT=$(readlink -e $0)

# Directory housing script
SCRIPTPATH=$(dirname $SCRIPT)

. $CONJURE_UP_SPELLSDIR/sdk/common.sh

if [[ "$JUJU_PROVIDERTYPE" == "lxd" ]]; then
    debug "Running pre-deploy for $CONJURE_UP_SPELL"
    sed "s/##MODEL##/$JUJU_MODEL/" $SCRIPTPATH/lxd-profile.yaml | lxc profile edit "juju-$JUJU_MODEL" || exposeResult "Failed to set profile" $? "false"
fi

exposeResult "Successful pre-deploy." 0 "true"

This would allow the provider lxd process a LXD profile, in this case we know we can apply provider specific properties. The YAML could also interpolate variables defined via environment variables.

Deploy Done

Waiting for applications to be complete can be challenging, one way to solve this is to list the initial applications to be deployed and the expected status.

Proposal

Is to use juju-wait for determining when a deployment is ready. We can accomplish this 2 ways, code this check into conjure-up itself and remove the use of 00-deploy_done or give the user the flexibility to define their own idea of a ready deployment and have this as an alternative as seen https://github.com/conjure-up/spells/pull/43.

Clone this wiki locally