- Mandatory Host Dependencies
- Optional Host Dependencies
- Building on Specific Distributions
- Definitions
- Architecture
-
An IAAS platform of some type - the developers typically test with OpenStack
- To build without, ./configure --disable-transport-ssh2
- To build without, ./configure --disable-transport-matahari
- To build without, ./configure --disable-transport-cim
- To build without, ./configure --disable-api-deltacloud
- m2crypto
- python-libguestfs
- python-qpid-qmf
- python-daemon
fedora15# yum install autoconf automake gcc-c++ glib2-devel libqb-devel \
dbus-glib-devel libxml2-devel pacemaker-libs-devel libtool-ltdl-devel \
qpid-cpp-client-devel qpid-qmf-devel libmicrohttpd-devel libcurl-devel
fedora15# make rpm
fedora15# rpm -ivh $(arch)/*.rpm
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 pacemaker-libs-devel libtool-ltdl-devel \
libmicrohttpd-devel libcurl-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
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
Description of the program flow given some different scenarios:
- Cloud management software sends cpe the assembly & service config in XML (via QMF). Note very simerlar to what pacemaker PE wants.
- CPE asks upstart/systemd to start a new DPE.
- CPE stores the config somewhere (DB or file)
- CPE waits for the DPE QMF agent to be available, then asks it to load the config and managemt the deployment.
- DPE gathers config + state and sends it to the PE
- DPE performs the actions (using matahari) as instructed by PE
- Cloud managemt software tells CPE to destroy a deployment
- CPE asks upstart/systemd to stop the DPE and deletes the config
- CPE notices death of CPE and starts a new one
- CPE waits for the DPE QMF agent to be available, then asks it to load the config and managemt the deployment.
- DPE gathers config + state and sends it to the PE
- DPE performs the actions (using matahari) as instructed by PE
- DPE notices the Assembly has missed a heartbeat.
- send a QMF event (assembly failure)
- DPE gathers config + state and sends it to the PE
- DPE performs the actions (using matahari) as instructed by PE (move services to other assemblies)
- Cloud management software sends cpe the assembly & service config in XML (via QMF). Note very simerlar to what pacemaker PE wants.
- CPE sees the DPE is already running.
- CPE stores the config somewhere (DB or file)
- CPE then notifys the DPE that the config has changed.
- DPE gathers config + state and sends it to the PE
- DPE performs the actions (using matahari) as instructed by PE
- 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.