rpedde

#!/bin/bash

set -e

dsh -Mcg swift-storage sudo /usr/local/bin/swift-partition.sh xvdb
dsh -Mcg swift-storage sudo /usr/local/bin/swift-format.sh xvdb1
dsh -Mcg swift-storage sudo mkdir -p /srv/node/disk1
dsh -Mcg swift-storage sudo mount /dev/xvdb1 /srv/node/disk1
dsh -Mcg swift-storage sudo chown -R swift: /srv/node/disk1

rpedde

Installing Custom Middleware

Sometimes, middleware needs to be added or configured differently than the assumptions made in the swift-private-cloud cookbook.

Fortunately, there are provisions for modifying to configurations to achieve different goals.

As an example, let's install Swift's "Static Web" middleware, as described in the [OpenStack Object Storage

rpedde

Environment Hackery

Sometimes the assumptions in swift-private-cloud are wrong. They don't fit the customer environment, or a one-off configuration makes the assumptions invalid (this never happens).

When it does happen, you'll be happy to know that the swift-private-cloud cookbooks are much more configurable than the old swift cookbooks, and significantly more configurable than the nova cookbooks as well.

If you are thinking you need to override something, or change the behavior of a deployed swift cluster, you probably can. Without having to drop the cluster out of config management.

Built-in Assumptions

rpedde

#!/bin/bash

_uberosc() {
    local cur=${COMP_WORDS[COMP_CWORD]}
    COMPREPLY=( $(compgen -W "$(pushd ${HOME}/.osc > /dev/null 2>&1; ls *; popd > /dev/null 2>&1)" -- $cur) )
}

uberosc() {
    local env=${1}

rpedde

#!/bin/bash

_ubernova() {
    local cur=${COMP_WORDS[COMP_CWORD]}
    COMPREPLY=( $(compgen -W "$(pushd ${HOME}/.ubernova > /dev/null 2>&1; ls *; popd > /dev/null 2>&1)" -- $cur) )
}

ubernova() {
    local env=${1}

rpedde

RPCDAEMON

Overview

Currently, OpenStack Havana does not have built-in support for highly availabile virtual routers or DHCP services. In the existing Havana release, virtual routers and DHCP services are scheduled to a single Quantum network node, and are not rescheduled on network node failure.

Since virtual router and DHCP services are normally scheduled

rpedde

Requirements

• Minimize code and deps in ZeroVM proper
• Make the back-end networking implementation interchangeable
• Make the back-end services extensible

Proposal

The problem of implementing a networking interface to ZeroVM breaks down into two separate but related problems:

rpedde

[
    {
	"name" : "watermark",
	"exec" : {
	        "path": "swift://AUTH_f6d34e39-ae2b-4d29-96f6-c35d70d8a4ca/watermark/watermark"
    },
	"file_list" : [
	    {"device": "stdin",
	     "path": "swift://AUTH_f6d34e39-ae2b-4d29-96f6-c35d70d8a4ca/watermark/space.jpg"},
	    {"device": "stdout",

rpedde

#!/usr/bin/env python

import requests
import json
import sys
import os

def get_url_and_token():
    user = os.getenv('ST_USER', None)
    auth = os.getenv('ST_AUTH', None)

rpedde

rpedde@hafnium:~$ xrandr
Screen 0: minimum 8 x 8, current 5120 x 1440, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   2560x1440     59.95*+
   1920x1080     60.00  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81