Pacemaker Cloud Policy Engine
C++ Python C Shell
Switch branches/tags
Nothing to show
Pull request Compare This branch is 411 commits behind sdake:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
src
tests
.gitignore
COPYING
Makefile.am
NEWS
README.markdown
TODO
autogen.sh
configure.ac
pacemaker-cloud.spec.in

README.markdown

Cloud Policy Engine


Table of Contents

  1. Dependencies
  2. Building on Specific Distributions
  3. Definitions
  4. Architecture

1) Dependencies

2) Building on Specific Distributions

Installing on Fedora 15:

fedora15# yum install autoconf automake gcc-c++ glib2-devel libqb-devel dbus-glib-devel libxml2-devel libqb-devel pacemaker-libs-devel libtool-ltdl-devel qpid-cpp-client-devel qpid-qmf-devel
fedora15# make rpm
fedora15# rpm -ivh $(arch)/*.rpm

Installing on Fedora 14:

qpid on f14 is out of date. libqb is not available in f14. Please obtain copies of the source tree from section 1 for those packages and build from source. Note on 64 bit systems, qpid does not autodetect the libdir is 64 bit, so --libdir=/usr/lib64 must be specified.

fedora14# yum install autoconf automake gcc-c++ glib2-devel dbus-glib-devel libxml2-devel libqb-devel pacemaker-libs-devel libtool-ltdl-devel
fedora14# cd libqb
fedora14# make rpm
fedora14# rpm -ivh $(arch)/*.rpm

install qpid, overwriting your default install

fedora14# make rpm
fedora14# rpm -ivh $(arch)/*.rpm

3) Definitions

Assembly = user defined guest composed of a VM image, Matahari active monitoring agent, boot configuration tools, and applications

Deployable = user defined set of assemblies and services

CPE = Cloud Policy Engine, starts and stops DPE's

DPE = Deployable Policy Engine, controls the services in a customer deployment

4) Architecture

Description of the program flow given some different scenarios:

Create new deployment

  1. Cloud management software sends cpe the assembly & service config in XML (via QMF). Note very simerlar to what pacemaker PE wants.
  2. CPE asks upstart/systemd to start a new DPE.
  3. CPE stores the config somewhere (DB or file)
  4. CPE waits for the DPE QMF agent to be available, then asks it to load the config and managemt the deployment.
  5. DPE gathers config + state and sends it to the PE
  6. DPE performs the actions (using matahari) as instructed by PE

Destroy deployment

  1. Cloud managemt software tells CPE to destroy a deployment
  2. CPE asks upstart/systemd to stop the DPE and deletes the config

DPE dies or gets restarted

  1. CPE notices death of CPE and starts a new one
  2. CPE waits for the DPE QMF agent to be available, then asks it to load the config and managemt the deployment.
  3. DPE gathers config + state and sends it to the PE
  4. DPE performs the actions (using matahari) as instructed by PE

Assembly Instance misses heartbeat

  1. DPE notices the Assembly has missed a heartbeat.
  2. send a QMF event (assembly failure)
  3. DPE gathers config + state and sends it to the PE
  4. DPE performs the actions (using matahari) as instructed by PE (move services to other assemblies)

User modifies the deployment configuration

  1. Cloud management software sends cpe the assembly & service config in XML (via QMF). Note very simerlar to what pacemaker PE wants.
  2. CPE sees the DPE is already running.
  3. CPE stores the config somewhere (DB or file)
  4. CPE then notifys the DPE that the config has changed.
  5. DPE gathers config + state and sends it to the PE
  6. DPE performs the actions (using matahari) as instructed by PE

User accesses the event log.

  1. cloud management software accesses event log Since CPE/DPE is only one part of the cloud software the logs need to be inserted into a larger picture. So we need an API to log important events.