Merge lp:~evilnick/clouddocs/reorg into lp:~jujudocs/clouddocs/trunk

[Nick Veitch]

I have reorganised the Install and Admin sections into their own directories - this is sort of necessary for making sense of converting them into separate HTMl docs for web.

=== added directory 'Admin'
=== added file 'Admin/Appendix-Ceph-and-OpenStack.md'
--- Admin/Appendix-Ceph-and-OpenStack.md	1970-01-01 00:00:00 +0000
+++ Admin/Appendix-Ceph-and-OpenStack.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,229 @@
+Title: Appendix - Ceph and OpenStack
+Status: Done
+
+# Appendix: Ceph and OpenStack
+
+Ceph stripes block device images as objects across a cluster. This way it provides
+a better performance than standalone server. OpenStack is able to use Ceph Block Devices
+through `libvirt`, which configures the QEMU interface to `librbd`. 
+
+To use Ceph Block Devices with OpenStack, you must install QEMU, `libvirt`, and OpenStack 
+first. It's recommended to use a separate physical node for your OpenStack installation. 
+OpenStack recommends a minimum of 8GB of RAM and a quad-core processor. 
+
+Three parts of OpenStack integrate with Ceph’s block devices:
+
+- Images: OpenStack Glance manages images for VMs. Images are immutable. OpenStack 
+  treats images as binary blobs and downloads them accordingly.
+- Volumes: Volumes are block devices. OpenStack uses volumes to boot VMs, or to 
+  attach volumes to running VMs. OpenStack manages volumes using Cinder services.
+- Guest Disks: Guest disks are guest operating system disks. By default, when you 
+  boot a virtual machine, its disk appears as a file on the filesystem of the 
+  hypervisor (usually under /var/lib/nova/instances/<uuid>/). Prior OpenStack Havana, 
+  the only way to boot a VM in Ceph was to use the boot from volume functionality 
+  from Cinder. However, now it is possible to directly boot every virtual machine 
+  inside Ceph without using Cinder. This is really handy because it allows us to 
+  easily perform maintenance operation with the live-migration process. On the other 
+  hand, if your hypervisor dies it is also really convenient to trigger Nova evacuate 
+  and almost seamlessly run the virtual machine somewhere else.
+
+You can use OpenStack Glance to store images in a Ceph Block Device, and you can 
+use Cinder to boot a VM using a copy-on-write clone of an image.
+
+## Create a pool
+
+By default, Ceph block devices use the `rbd` pool. You may use any available pool. 
+We recommend creating a pool for Cinder and a pool for Glance. Ensure your Ceph 
+cluster is running, then create the pools.
+
+````
+ceph osd pool create volumes 128
+ceph osd pool create images 128
+ceph osd pool create backups 128
+````
+
+## Configure OpenStack Ceph Clients
+
+The nodes running `glance-api`, `cinder-volume`, `nova-compute` and `cinder-backup` act 
+as Ceph clients. Each requires the `ceph.conf` file
+
+````
+ssh {your-openstack-server} sudo tee /etc/ceph/ceph.conf </etc/ceph/ceph.conf
+````
+
+On the `glance-api` node, you’ll need the Python bindings for `librbd`
+
+````
+sudo apt-get install python-ceph
+sudo yum install python-ceph
+````
+
+On the `nova-compute`, `cinder-backup` and on the `cinder-volume` node, use both the 
+Python bindings and the client command line tools
+
+````
+sudo apt-get install ceph-common
+sudo yum install ceph
+````
+
+If you have cephx authentication enabled, create a new user for Nova/Cinder and 
+Glance. Execute the following
+
+````
+ceph auth get-or-create client.cinder mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rx pool=images'
+ceph auth get-or-create client.glance mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'
+ceph auth get-or-create client.cinder-backup mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=backups'
+````
+
+Add the keyrings for `client.cinder`, `client.glance`, and `client.cinder-backup` 
+to the appropriate nodes and change their ownership
+
+````
+ceph auth get-or-create client.glance | ssh {your-glance-api-server} sudo tee /etc/ceph/ceph.client.glance.keyring
+ssh {your-glance-api-server} sudo chown glance:glance /etc/ceph/ceph.client.glance.keyring
+ceph auth get-or-create client.cinder | ssh {your-volume-server} sudo tee /etc/ceph/ceph.client.cinder.keyring
+ssh {your-cinder-volume-server} sudo chown cinder:cinder /etc/ceph/ceph.client.cinder.keyring
+ceph auth get-or-create client.cinder-backup | ssh {your-cinder-backup-server} sudo tee /etc/ceph/ceph.client.cinder-backup.keyring
+ssh {your-cinder-backup-server} sudo chown cinder:cinder /etc/ceph/ceph.client.cinder-backup.keyring
+````
+
+Nodes running `nova-compute` need the keyring file for the `nova-compute` process. 
+They also need to store the secret key of the `client.cinder` user in `libvirt`. The 
+`libvirt` process needs it to access the cluster while attaching a block device 
+from Cinder.
+
+Create a temporary copy of the secret key on the nodes running `nova-compute`
+
+````
+ceph auth get-key client.cinder | ssh {your-compute-node} tee client.cinder.key
+````
+
+Then, on the compute nodes, add the secret key to `libvirt` and remove the 
+temporary copy of the key
+
+````
+uuidgen
+457eb676-33da-42ec-9a8c-9293d545c337
+
+cat > secret.xml <<EOF
+<secret ephemeral='no' private='no'>
+  <uuid>457eb676-33da-42ec-9a8c-9293d545c337</uuid>
+  <usage type='ceph'>
+    <name>client.cinder secret</name>
+  </usage>
+</secret>
+EOF
+sudo virsh secret-define --file secret.xml
+Secret 457eb676-33da-42ec-9a8c-9293d545c337 created
+sudo virsh secret-set-value --secret 457eb676-33da-42ec-9a8c-9293d545c337 --base64 $(cat client.cinder.key) && rm client.cinder.key secret.xml
+````
+
+Save the uuid of the secret for configuring `nova-compute` later.
+
+**Important** You don’t necessarily need the UUID on all the compute nodes. 
+However from a platform consistency perspective it’s better to keep the 
+same UUID.
+
+## Configure OpenStack to use Ceph
+
+### Glance
+
+Glance can use multiple back ends to store images. To use Ceph block devices 
+by default, edit `/etc/glance/glance-api.conf` and add
+
+````
+default_store=rbd
+rbd_store_user=glance
+rbd_store_pool=images
+````
+
+If want to enable copy-on-write cloning of images into volumes, also add:
+
+````
+show_image_direct_url=True
+````
+
+Note that this exposes the back end location via Glance’s API, so 
+the endpoint with this option enabled should not be publicly 
+accessible.
+
+### Cinder
+
+OpenStack requires a driver to interact with Ceph block devices. You 
+must also specify the pool name for the block device. On your 
+OpenStack node, edit `/etc/cinder/cinder.conf` by adding
+
+````
+volume_driver=cinder.volume.drivers.rbd.RBDDriver
+rbd_pool=volumes
+rbd_ceph_conf=/etc/ceph/ceph.conf
+rbd_flatten_volume_from_snapshot=false
+rbd_max_clone_depth=5
+glance_api_version=2
+````
+
+If you’re using cephx authentication, also configure the user and 
+uuid of the secret you added to `libvirt` as documented earlier
+
+````
+rbd_user=cinder
+rbd_secret_uuid=457eb676-33da-42ec-9a8c-9293d545c337
+````
+
+## Cinder Backup
+
+OpenStack Cinder Backup requires a specific daemon so don’t 
+forget to install it. On your Cinder Backup node, 
+edit `/etc/cinder/cinder.conf` and add:
+
+````
+backup_driver=cinder.backup.drivers.ceph
+backup_ceph_conf=/etc/ceph/ceph.conf
+backup_ceph_user=cinder-backup
+backup_ceph_chunk_size=134217728
+backup_ceph_pool=backups
+backup_ceph_stripe_unit=0
+backup_ceph_stripe_count=0
+restore_discard_excess_bytes=true
+````
+
+### Nova
+
+In order to boot all the virtual machines directly into Ceph Nova must be 
+configured. On every Compute nodes, edit `/etc/nova/nova.conf` and add
+
+````
+libvirt_images_type=rbd
+libvirt_images_rbd_pool=volumes
+libvirt_images_rbd_ceph_conf=/etc/ceph/ceph.conf
+rbd_user=cinder
+rbd_secret_uuid=457eb676-33da-42ec-9a8c-9293d545c337
+````
+
+It is also a good practice to disable any file injection. Usually, while 
+booting an instance Nova attempts to open the rootfs of the virtual machine. 
+Then, it injects directly into the filesystem things like: password, ssh 
+keys etc... At this point, it is better to rely on the metadata service 
+and cloud-init. On every Compute nodes, edit `/etc/nova/nova.conf` and add
+
+````
+libvirt_inject_password=false
+libvirt_inject_key=false
+libvirt_inject_partition=-2
+````
+
+## Restart OpenStack
+
+To activate the Ceph block device driver and load the block device pool name 
+into the configuration, you must restart OpenStack. 
+
+````
+sudo glance-control api restart
+sudo service nova-compute restart
+sudo service cinder-volume restart
+sudo service cinder-backup restart
+````
+
+Once OpenStack is up and running, you should be able to create a volume 
+and boot from it.
+
 
=== added file 'Admin/Backup-and-Recovery-Ceph.md'
--- Admin/Backup-and-Recovery-Ceph.md	1970-01-01 00:00:00 +0000
+++ Admin/Backup-and-Recovery-Ceph.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,107 @@
+Title: Backup and Recovery - Ceph
+Status: In Progress
+
+# Backup and Recovery - Ceph
+
+## Introduction
+
+A snapshot is a read-only copy of the state of an image at a particular point in time. One 
+of the advanced features of Ceph block devices is that you can create snapshots of the images 
+to retain a history of an image’s state. Ceph also supports snapshot layering, which allows 
+you to clone images (e.g., a VM image) quickly and easily. Ceph supports block device snapshots 
+using the `rbd` command and many higher level interfaces including OpenStack.
+
+## Scope
+
+**TODO**
+
+## Backup
+
+To create a snapshot with `rbd`, specify the `snap create` option, the pool name and the 
+image name.
+
+````
+rbd --pool {pool-name} snap create --snap {snap-name} {image-name}
+rbd snap create {pool-name}/{image-name}@{snap-name}
+````
+
+For example:
+
+````
+rbd --pool rbd snap create --snap snapname foo
+rbd snap create rbd/foo@snapname
+````
+
+## Restore
+
+To rollback to a snapshot with `rbd`, specify the `snap rollback` option, the pool name, the 
+image name and the snap name.
+
+````
+rbd --pool {pool-name} snap rollback --snap {snap-name} {image-name}
+rbd snap rollback {pool-name}/{image-name}@{snap-name}
+````
+
+For example:
+
+````
+rbd --pool rbd snap rollback --snap snapname foo
+rbd snap rollback rbd/foo@snapname
+````
+
+**Note:** Rolling back an image to a snapshot means overwriting the current version of the image 
+with data from a snapshot. The time it takes to execute a rollback increases with the size of the 
+image. It is faster to clone from a snapshot than to rollback an image to a snapshot, and it is 
+the preferred method of returning to a pre-existing state.
+
+## Maintenance
+
+Taking snapshots increases your level of security but also costs disk space. To delete older ones
+you can list them, delete individual ones or purge all snapshots.
+
+To list snapshots of an image, specify the pool name and the image name.
+
+````
+rbd --pool {pool-name} snap ls {image-name}
+rbd snap ls {pool-name}/{image-name}
+````
+
+For example:
+
+````
+rbd --pool rbd snap ls foo
+rbd snap ls rbd/foo
+````
+
+To delete a snapshot with `rbd`, specify the `snap rm` option, the pool name, the image name 
+and the username.
+
+````
+rbd --pool {pool-name} snap rm --snap {snap-name} {image-name}
+rbd snap rm {pool-name}/{image-name}@{snap-name}
+````
+
+For example:
+
+````
+rbd --pool rbd snap rm --snap snapname foo
+rbd snap rm rbd/foo@snapname
+````
+
+**Note:** Ceph OSDs delete data asynchronously, so deleting a snapshot doesn’t free up the 
+disk space immediately.
+
+To delete all snapshots for an image with `rbd`, specify the snap purge option and the 
+image name.
+
+````
+rbd --pool {pool-name} snap purge {image-name}
+rbd snap purge {pool-name}/{image-name}
+````
+
+For example:
+
+````
+rbd --pool rbd snap purge foo
+rbd snap purge rbd/foo
+````
 
=== added file 'Admin/Backup-and-Recovery-Juju.md'
--- Admin/Backup-and-Recovery-Juju.md	1970-01-01 00:00:00 +0000
+++ Admin/Backup-and-Recovery-Juju.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,59 @@
+Title: Backup and Recovery - Juju
+Status: In Progress
+
+# Backup and Recovery - Juju
+
+## Introduction
+
+**TODO**
+
+## Scope
+
+**TODO**
+
+## Backup
+
+Jujus working principle is based on storing the state of the cloud in
+database containing information about the environment, machines, services,
+and units. Changes to an environment are made to the state first, which are
+then detected by their according agents. Those are responsible to do the
+needed steps then.
+
+This principle allows Juju to easily do a *backup* of this information, plus
+some needed configuration data and some more useful information more. The 
+command to do so is `juju-backup`, which saves the currently selected 
+environment. So please make sure to switch to the environment you want to 
+backup.
+
+````
+$ juju switch my-env
+$ juju backup
+````
+
+The command creates two generations of backups on the bootstrap node, also
+know as `machine-0`. Beside the state and configuration data about this machine
+itself and the other ones of its environment the aggregated log for all
+machines and the one of this machine itself are saved. The aggregated log
+is the same you're accessing when calling
+
+````
+$ juju debug-log
+````
+
+and enables you to retrieve helpful information in case of a problem. After
+the backup is created on the bootstrap node it is transferred to your 
+working machine into the current directory as `juju-backup-YYYYMMDD-HHMM.tgz`,
+where *YYYYMMDD-HHMM* is date and time of the backup. In case you want to open 
+the backup manually to access the mentioned logging data you'll find it in the 
+contained archive `root.tar`. Here please don't wonder, this way all owner, 
+access rights and other information are preserved.
+
+## Restore
+
+To *restore* an environment the according command is 
+
+````
+$ juju restore <BACKUPFILE>
+````
+
+This way you're able to choose the concrete environment to restore.
 
=== added file 'Admin/Backup-and-Recovery-OpenStack.md'
--- Admin/Backup-and-Recovery-OpenStack.md	1970-01-01 00:00:00 +0000
+++ Admin/Backup-and-Recovery-OpenStack.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,131 @@
+Title: Backup and Recovery - OpenStack
+Status: In Progress
+
+# Backup and Recovery - OpenStack
+
+## Introduction
+
+The OpenStack flexibility makes backup and restore to a very individual process
+depending on the used components. This section describes how the critical parts
+like the configuration files and databases OpenStack needs to run are saved. As
+before for Juju it doesn't describe ho to back up the objects inside the Object 
+Storage or the data inside the Block Storage.
+
+## Scope
+
+**TODO**
+
+## Backup Cloud Controller Database
+
+Like Juju the OpenStack cloud controller uses a database server which stores the
+central databases for Nova, Glance, Keystone, Cinder, and Switft. You can backup
+the five databases into one common dump:
+
+````
+$ mysqldump --opt --all-databases > openstack.sql
+````
+
+Alternatively you can backup the database for each component individually:
+
+````
+$ mysqldump --opt nova > nova.sql
+$ mysqldump --opt glance > glance.sql
+$ mysqldump --opt keystone > keystone.sql
+$ mysqldump --opt cinder > cinder.sql
+$ mysqldump --opt swift > swift.sql
+````
+
+## Backup File Systems
+
+Beside the databases OpenStack uses different directories for its configuration,
+runtime files, and logging. Like the databases they are grouped individually per
+component. This way also the backup can be done per component.
+
+### Nova
+
+You'll find the configuration directory `/etc/nova` on the cloud controller and 
+each compute node. It should be regularly backed up.
+
+Another directory to backup is `/var/lib/nova`. But here you have to be careful
+with the `instances` subdirectory on the compute nodes. It contains the KVM images
+of the running instances. If you want to maintain backup copies of those instances
+you can do a backup here too. In this case make sure to not save a live KVM instance
+because it may not boot properly after restoring the backup.
+
+Third directory for the compute component is `/var/log/nova`. In case of a central
+logging server this directory does not need to be backed up. So we suggest you to
+run your environment with this kind of logging.
+
+### Glance
+
+Like for Nova you'll find the directories `/etc/glance` and `/var/log/glance`, the
+handling should be the same here too.
+
+Glance also uses the directory named `/var/lib/glance` which also should be backed
+up.
+
+### Keystone
+
+Keystone is using the directories `/etc/keystone`, `/var/lib/keystone`, and
+`/var/log/keystone`. They follow the same rules as Nova and Glance. Even if
+the `lib` directory should not contain any data being used, can also be backed 
+up just in case.
+
+### Cinder
+
+Like before you'll find the directories `/etc/cinder`, `/var/log/cinder`,
+and `/var/lib/cinder`. And also here the handling should be the same. Opposite
+to Nova abd Glance there's no special handling of `/var/lib/cinder` needed.
+
+### Swift
+
+Beside the Swift configuration the directory `/etc/swift` contains the ring files
+and the ring builder files. If those get lest the data on your data gets inaccessable.
+So you can easily imagine how important it is to backup this directory. Best practise
+is to copy the builder files to the storage nodes along with the ring files. So
+multiple copies are spread throughout the cluster.
+
+**TODO(mue)** Really needed when we use Ceph for storage?
+
+## Restore
+
+The restore based on the backups is a step-by-step process restoring the components
+databases and all their directories. It's important that the component to restore is 
+currently not running. So always start the restoring with stopping all components.
+
+Let's take Nova as an example. First execute
+
+````
+$ stop nova-api
+$ stop nova-cert
+$ stop nova-consoleauth
+$ stop nova-novncproxy
+$ stop nova-objectstore
+$ stop nova-scheduler
+````
+
+on the cloud controller to savely stop the processes of the component. Next step is the
+restore of the database. By using the `--opt` option during backup we ensured that all
+tables are initially dropped and there's no conflict with currently existing data in
+the databases.
+
+````
+$ mysql nova < nova.sql
+````
+
+Before restoring the directories you should move at least the configuration directoy,
+here `/etc/nova`, into a secure location in case you need to roll it back.
+
+After the database and the files are restored you can start MySQL and Nova again.
+
+````
+$ start mysql
+$ start nova-api
+$ start nova-cert
+$ start nova-consoleauth
+$ start nova-novncproxy
+$ start nova-objectstore
+$ start nova-scheduler
+````
+
+The process for the other components look similar.
 
=== added file 'Admin/Logging-Juju.md'
--- Admin/Logging-Juju.md	1970-01-01 00:00:00 +0000
+++ Admin/Logging-Juju.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,24 @@
+Title: Logging - Juju
+Status: In Progress
+
+# Logging - Juju
+
+## Introduction
+
+**TODO**
+
+## Scope
+
+**TODO**
+
+## Connecting to rsyslogd
+
+Juju already uses `rsyslogd` for the aggregation of all logs into on centralized log. The
+target of this logging is the file `/var/log/juju/all-machines.log`. You can directly
+access it using the command
+
+````
+$ juju debug-log
+````
+
+**TODO** Describe a way to redirect this log to a central rsyslogd server.
 
=== added file 'Admin/Logging-OpenStack.md'
--- Admin/Logging-OpenStack.md	1970-01-01 00:00:00 +0000
+++ Admin/Logging-OpenStack.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,92 @@
+Title: Logging - OpenStack
+Status: In Progress
+
+# Logging - OpenStack
+
+## Introduction
+
+**TODO**
+
+## Scope
+
+**TODO**
+
+## Connecting to rsyslogd
+
+By default OpenStack is writting its logging output into files into directories for each
+component, like `/var/log/nova` or `/var/log/glance`. For the usage of `rsyslogd` the components
+have to be configured to also log to `syslog`. When doing this also configure each component
+to log into a different syslog facility. This will help you to split the logs into individual
+components on the central logging server. So ensure the following settings:
+
+**/etc/nova/nova.conf:**
+
+````
+use_syslog=True
+syslog_log_facility=LOG_LOCAL0
+````
+
+**/etc/glance/glance-api.conf and /etc/glance/glance-registry.conf:**
+
+````
+use_syslog=True
+syslog_log_facility=LOG_LOCAL1
+````
+
+**/etc/cinder/cinder.conf:**
+
+````
+use_syslog=True
+syslog_log_facility=LOG_LOCAL2
+````
+
+**/etc/keystone/keystone.conf:**
+
+````
+use_syslog=True
+syslog_log_facility=LOG_LOCAL3
+````
+
+The object storage Swift be fault already logs to syslog. So you now can tell the local
+rsyslogd clients to pass the logged information to the logging server. You'll do this
+by creating a `/etc/rsyslog.d/client.conf` containing the line like
+
+````
+*.* @192.16.1.10
+````
+
+where the IP address points to your rsyslogd server. Best is to choose a server that is
+dedicated to this task only. Here you've got to create the file `/etc/rsyslog.d/server.conf`
+contining the settings
+
+````
+# Enable UDP
+$ModLoad imudp
+# Listen on 192.168.1.10 only
+$UDPServerAddress 192.168.1.10
+# Port 514
+$UDPServerRun 514
+# Create logging templates for nova
+$template NovaFile,"/var/log/rsyslog/%HOSTNAME%/nova.log"
+$template NovaAll,"/var/log/rsyslog/nova.log"
+# Log everything else to syslog.log
+$template DynFile,"/var/log/rsyslog/%HOSTNAME%/syslog.log"
+*.* ?DynFile
+# Log various openstack components to their own individual file
+local0.* ?NovaFile
+local0.* ?NovaAll
+& ~
+````
+
+This example only contains the settings for Nova only, the other OpenStack components
+have to be added the same way. Using two templates per component, one containing the 
+`%HOSTNAME%` variable and one without it enables a better splitting of the logged 
+data. Think about the two example nodes `alpha.example.com` and `bravo.example.com`.
+They will write their logging into the files
+
+- `/var/log/rsyslog/alpha.example.com/nova.log` - only the data of alpha,
+- `/var/log/rsyslog/bravo.example.com/nova.log` - only the data of bravo,
+- `/var/log/rsyslog/nova.log` - the combined data of both.
+
+This allows a quick overview over all nodes as well as the focussed analysis of an
+individual node.
 
=== added file 'Admin/Logging.md'
--- Admin/Logging.md	1970-01-01 00:00:00 +0000
+++ Admin/Logging.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,15 @@
+Title: Logging
+Status: In Progress
+
+# Logging
+
+The controlling of individual logs is a cumbersome job, even in an environment with only
+few computer system. But it's even more worse in typical clouds with a large number of
+nodes. Here the centrallized approach using `rsyslogd` helps. It allows you to aggregate
+the logging output of all systems in one place. Here the monitoring and analysis gets
+more simple.
+
+Ubuntu uses `rsyslogd` as the default logging service. Since it is natively able to send 
+logs to a remote location, you don't have to install anything extra to enable this feature, 
+just modify the configuration file. In doing this, consider running your logging over 
+a management network or using an encrypted VPN to avoid interception.
 
=== added file 'Admin/Scaling-Ceph.md'
--- Admin/Scaling-Ceph.md	1970-01-01 00:00:00 +0000
+++ Admin/Scaling-Ceph.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,36 @@
+Title: Scaling - Ceph
+Status: In Progress
+
+# Scaling - Ceph
+
+## Introduction
+
+Beside the redundancy for more safety and the higher performance through the usage of 
+Ceph as storage backend for OpenStack the user also benefits from the more simple way
+of scaling the storage of the needs grow.
+
+## Scope
+
+**TODO**
+
+## Scaling
+
+The addition of Ceph nodes is done using the Juju `add-node` command. By default
+it adds only one node, but it is possible to add the number of wanted nodes as
+argument. To add one more Ceph OSD Daemon node you simply call
+
+```
+juju add-node ceph-osd
+```
+
+Larger numbers of nodes can be added using the `-n` argument, e.g. 5 nodes
+with
+
+```
+juju add-node -n 5 ceph-osd
+```
+
+**Attention:** The adding of more nodes to Ceph leads to a redistribution of data
+between the nodes of an image. This can cause inefficiencies during this process. So
+it should be done in smaller steps.
+
 
=== added file 'Admin/Upgrading-and-Patching-Juju.md'
--- Admin/Upgrading-and-Patching-Juju.md	1970-01-01 00:00:00 +0000
+++ Admin/Upgrading-and-Patching-Juju.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,45 @@
+Title: Upgrading and Patching - Juju
+Status: In Progress
+
+# Upgrading and Patching - Juju
+
+## Introduction
+
+**TODO**
+
+## Scope
+
+**TODO**
+
+## Upgrading
+
+The upgrade of a Juju environment is done using the Juju client and its command
+
+````
+$ juju upgrade-juju
+````
+
+This command sets the version number for all Juju agents to run. This by default
+is the most recent supported version compatible with the comand-line tools version.
+So ensure that you've upgraded the Juju client first.
+
+When run without arguments, `upgrade-juju` will try to upgrade to the following 
+versions, in order of preference and depending on the current value of the 
+environment's `agent-version` setting:
+
+- The highest patch.build version of the *next* stable major.minor version.
+- The highest patch.build version of the *current* major.minor version.
+
+Both of these depend on the availability of the according tools. On MAAS you've
+got to manage this yourself using the command
+
+````
+$ juju sync-tools
+````
+
+This copies the Juju tools tarball from the official tools store (located
+at https://streams.canonical.com/juju) into your environment.
+
+## Patching
+
+**TODO**
 
=== added file 'Admin/Upgrading-and-Patching-OpenStack.md'
--- Admin/Upgrading-and-Patching-OpenStack.md	1970-01-01 00:00:00 +0000
+++ Admin/Upgrading-and-Patching-OpenStack.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,83 @@
+Title: Upgrading and Patching - OpenStack
+Status: In Progress
+
+# Upgrading and Patching - OpenStack
+
+## Introduction
+
+**TODO**
+
+## Scope
+
+**TODO**
+
+## Upgrading
+
+The upgrade of an OpenStack cluster in one big step is an approach requiring additional
+hardware to setup an update cloud beside the productive one and leads to a longer
+outage while your cloud is in read-only mode, the state is transferred to the new
+one and the environments are switched. So the preferred way of upgrading an OpenStack
+cloud is the rolling upgrade of each component of the system piece by piece.
+
+Here you can choose between in-place and side-by-side upgrades. But the first one needs
+to shutdown the regarding component while you're performing its upgrade. Additionally you
+may have troubles in case of a rollback. So to avoid this the side by side upgrade is
+the preferred way here.
+
+Before starting the upgrade itself you should
+
+- Perform some "cleaning" of the environment process to ensure a consistent state; for 
+  example, instances not fully purged from the system after deletion may cause 
+  indeterminate behavior
+- Read the release notes and documentation
+- Find incompatibilities between your versions
+
+The upgrade tasks here follow the same procedure for each component:
+
+1. Configure the new worker
+1. Turn off the current worker; during this time hide the downtime using a message
+   queue or a load balancer
+1. Take a backup as described earlier of the old worker for a rollback
+1. Copy the state of the current to the new worker
+1. Start up the new worker
+
+Now repeat these steps for each worker in an approprate order. In case of a problem it
+should be easy to rollback as long as the former worker stays untouched. This is,
+beside the shorter downtime, the most important advantage of the side-by-side upgrade.
+
+The following order for service upgrades seems the most successful:
+
+1. Upgrade the OpenStack Identity Service (Keystone).
+1. Upgrade the OpenStack Image Service (Glance).
+1. Upgrade OpenStack Compute (Nova), including networking components.
+1. Upgrade OpenStack Block Storage (Cinder).
+1. Upgrade the OpenStack dashboard.
+
+These steps look very easy, but still are a complex procedure depending on your cloud
+configuration. So we recommend to have a testing environment with a near-identical
+architecture to your production system. This doesn't mean that you should use the same
+sizes and hardware, which would be best but expensive. But there are some ways to reduce
+the cost.
+
+- Use your own cloud. The simplest place to start testing the next version of OpenStack 
+  is by setting up a new environment inside your own cloud. This may seem odd—especially 
+  the double virtualisation used in running compute nodes—but it's a sure way to very 
+  quickly test your configuration.
+- Use a public cloud. Especially because your own cloud is unlikely to have sufficient 
+  space to scale test to the level of the entire cloud, consider using a public cloud 
+  to test the scalability limits of your cloud controller configuration. Most public 
+  clouds bill by the hour, which means it can be inexpensive to perform even a test 
+  with many nodes.
+- Make another storage endpoint on the same system. If you use an external storage plug-in 
+  or shared file system with your cloud, in many cases it's possible to test that it 
+  works by creating a second share or endpoint. This will enable you to test the system 
+  before entrusting the new version onto your storage.
+- Watch the network. Even at smaller-scale testing, it should be possible to determine 
+  whether something is going horribly wrong in intercomponent communication if you 
+  look at the network packets and see too many.
+
+**TODO** Add more concrete description here.
+
+## Patching
+
+**TODO**
 
=== removed file 'Appendix-Ceph-and-OpenStack.md'
--- Appendix-Ceph-and-OpenStack.md	2014-04-02 16:18:10 +0000
+++ Appendix-Ceph-and-OpenStack.md	1970-01-01 00:00:00 +0000
@@ -1,229 +0,0 @@
-Title: Appendix - Ceph and OpenStack
-Status: Done
-
-# Appendix: Ceph and OpenStack
-
-Ceph stripes block device images as objects across a cluster. This way it provides
-a better performance than standalone server. OpenStack is able to use Ceph Block Devices
-through `libvirt`, which configures the QEMU interface to `librbd`. 
-
-To use Ceph Block Devices with OpenStack, you must install QEMU, `libvirt`, and OpenStack 
-first. It's recommended to use a separate physical node for your OpenStack installation. 
-OpenStack recommends a minimum of 8GB of RAM and a quad-core processor. 
-
-Three parts of OpenStack integrate with Ceph’s block devices:
-
-- Images: OpenStack Glance manages images for VMs. Images are immutable. OpenStack 
-  treats images as binary blobs and downloads them accordingly.
-- Volumes: Volumes are block devices. OpenStack uses volumes to boot VMs, or to 
-  attach volumes to running VMs. OpenStack manages volumes using Cinder services.
-- Guest Disks: Guest disks are guest operating system disks. By default, when you 
-  boot a virtual machine, its disk appears as a file on the filesystem of the 
-  hypervisor (usually under /var/lib/nova/instances/<uuid>/). Prior OpenStack Havana, 
-  the only way to boot a VM in Ceph was to use the boot from volume functionality 
-  from Cinder. However, now it is possible to directly boot every virtual machine 
-  inside Ceph without using Cinder. This is really handy because it allows us to 
-  easily perform maintenance operation with the live-migration process. On the other 
-  hand, if your hypervisor dies it is also really convenient to trigger Nova evacuate 
-  and almost seamlessly run the virtual machine somewhere else.
-
-You can use OpenStack Glance to store images in a Ceph Block Device, and you can 
-use Cinder to boot a VM using a copy-on-write clone of an image.
-
-## Create a pool
-
-By default, Ceph block devices use the `rbd` pool. You may use any available pool. 
-We recommend creating a pool for Cinder and a pool for Glance. Ensure your Ceph 
-cluster is running, then create the pools.
-
-````
-ceph osd pool create volumes 128
-ceph osd pool create images 128
-ceph osd pool create backups 128
-````
-
-## Configure OpenStack Ceph Clients
-
-The nodes running `glance-api`, `cinder-volume`, `nova-compute` and `cinder-backup` act 
-as Ceph clients. Each requires the `ceph.conf` file
-
-````
-ssh {your-openstack-server} sudo tee /etc/ceph/ceph.conf </etc/ceph/ceph.conf
-````
-
-On the `glance-api` node, you’ll need the Python bindings for `librbd`
-
-````
-sudo apt-get install python-ceph
-sudo yum install python-ceph
-````
-
-On the `nova-compute`, `cinder-backup` and on the `cinder-volume` node, use both the 
-Python bindings and the client command line tools
-
-````
-sudo apt-get install ceph-common
-sudo yum install ceph
-````
-
-If you have cephx authentication enabled, create a new user for Nova/Cinder and 
-Glance. Execute the following
-
-````
-ceph auth get-or-create client.cinder mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rx pool=images'
-ceph auth get-or-create client.glance mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'
-ceph auth get-or-create client.cinder-backup mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=backups'
-````
-
-Add the keyrings for `client.cinder`, `client.glance`, and `client.cinder-backup` 
-to the appropriate nodes and change their ownership
-
-````
-ceph auth get-or-create client.glance | ssh {your-glance-api-server} sudo tee /etc/ceph/ceph.client.glance.keyring
-ssh {your-glance-api-server} sudo chown glance:glance /etc/ceph/ceph.client.glance.keyring
-ceph auth get-or-create client.cinder | ssh {your-volume-server} sudo tee /etc/ceph/ceph.client.cinder.keyring
-ssh {your-cinder-volume-server} sudo chown cinder:cinder /etc/ceph/ceph.client.cinder.keyring
-ceph auth get-or-create client.cinder-backup | ssh {your-cinder-backup-server} sudo tee /etc/ceph/ceph.client.cinder-backup.keyring
-ssh {your-cinder-backup-server} sudo chown cinder:cinder /etc/ceph/ceph.client.cinder-backup.keyring
-````
-
-Nodes running `nova-compute` need the keyring file for the `nova-compute` process. 
-They also need to store the secret key of the `client.cinder` user in `libvirt`. The 
-`libvirt` process needs it to access the cluster while attaching a block device 
-from Cinder.
-
-Create a temporary copy of the secret key on the nodes running `nova-compute`
-
-````
-ceph auth get-key client.cinder | ssh {your-compute-node} tee client.cinder.key
-````
-
-Then, on the compute nodes, add the secret key to `libvirt` and remove the 
-temporary copy of the key
-
-````
-uuidgen
-457eb676-33da-42ec-9a8c-9293d545c337
-
-cat > secret.xml <<EOF
-<secret ephemeral='no' private='no'>
-  <uuid>457eb676-33da-42ec-9a8c-9293d545c337</uuid>
-  <usage type='ceph'>
-    <name>client.cinder secret</name>
-  </usage>
-</secret>
-EOF
-sudo virsh secret-define --file secret.xml
-Secret 457eb676-33da-42ec-9a8c-9293d545c337 created
-sudo virsh secret-set-value --secret 457eb676-33da-42ec-9a8c-9293d545c337 --base64 $(cat client.cinder.key) && rm client.cinder.key secret.xml
-````
-
-Save the uuid of the secret for configuring `nova-compute` later.
-
-**Important** You don’t necessarily need the UUID on all the compute nodes. 
-However from a platform consistency perspective it’s better to keep the 
-same UUID.
-
-## Configure OpenStack to use Ceph
-
-### Glance
-
-Glance can use multiple back ends to store images. To use Ceph block devices 
-by default, edit `/etc/glance/glance-api.conf` and add
-
-````
-default_store=rbd
-rbd_store_user=glance
-rbd_store_pool=images
-````
-
-If want to enable copy-on-write cloning of images into volumes, also add:
-
-````
-show_image_direct_url=True
-````
-
-Note that this exposes the back end location via Glance’s API, so 
-the endpoint with this option enabled should not be publicly 
-accessible.
-
-### Cinder
-
-OpenStack requires a driver to interact with Ceph block devices. You 
-must also specify the pool name for the block device. On your 
-OpenStack node, edit `/etc/cinder/cinder.conf` by adding
-
-````
-volume_driver=cinder.volume.drivers.rbd.RBDDriver
-rbd_pool=volumes
-rbd_ceph_conf=/etc/ceph/ceph.conf
-rbd_flatten_volume_from_snapshot=false
-rbd_max_clone_depth=5
-glance_api_version=2
-````
-
-If you’re using cephx authentication, also configure the user and 
-uuid of the secret you added to `libvirt` as documented earlier
-
-````
-rbd_user=cinder
-rbd_secret_uuid=457eb676-33da-42ec-9a8c-9293d545c337
-````
-
-## Cinder Backup
-
-OpenStack Cinder Backup requires a specific daemon so don’t 
-forget to install it. On your Cinder Backup node, 
-edit `/etc/cinder/cinder.conf` and add:
-
-````
-backup_driver=cinder.backup.drivers.ceph
-backup_ceph_conf=/etc/ceph/ceph.conf
-backup_ceph_user=cinder-backup
-backup_ceph_chunk_size=134217728
-backup_ceph_pool=backups
-backup_ceph_stripe_unit=0
-backup_ceph_stripe_count=0
-restore_discard_excess_bytes=true
-````
-
-### Nova
-
-In order to boot all the virtual machines directly into Ceph Nova must be 
-configured. On every Compute nodes, edit `/etc/nova/nova.conf` and add
-
-````
-libvirt_images_type=rbd
-libvirt_images_rbd_pool=volumes
-libvirt_images_rbd_ceph_conf=/etc/ceph/ceph.conf
-rbd_user=cinder
-rbd_secret_uuid=457eb676-33da-42ec-9a8c-9293d545c337
-````
-
-It is also a good practice to disable any file injection. Usually, while 
-booting an instance Nova attempts to open the rootfs of the virtual machine. 
-Then, it injects directly into the filesystem things like: password, ssh 
-keys etc... At this point, it is better to rely on the metadata service 
-and cloud-init. On every Compute nodes, edit `/etc/nova/nova.conf` and add
-
-````
-libvirt_inject_password=false
-libvirt_inject_key=false
-libvirt_inject_partition=-2
-````
-
-## Restart OpenStack
-
-To activate the Ceph block device driver and load the block device pool name 
-into the configuration, you must restart OpenStack. 
-
-````
-sudo glance-control api restart
-sudo service nova-compute restart
-sudo service cinder-volume restart
-sudo service cinder-backup restart
-````
-
-Once OpenStack is up and running, you should be able to create a volume 
-and boot from it.
-
 
=== removed file 'Backup-and-Recovery-Ceph.md'
--- Backup-and-Recovery-Ceph.md	2014-04-02 16:18:10 +0000
+++ Backup-and-Recovery-Ceph.md	1970-01-01 00:00:00 +0000
@@ -1,107 +0,0 @@
-Title: Backup and Recovery - Ceph
-Status: In Progress
-
-# Backup and Recovery - Ceph
-
-## Introduction
-
-A snapshot is a read-only copy of the state of an image at a particular point in time. One 
-of the advanced features of Ceph block devices is that you can create snapshots of the images 
-to retain a history of an image’s state. Ceph also supports snapshot layering, which allows 
-you to clone images (e.g., a VM image) quickly and easily. Ceph supports block device snapshots 
-using the `rbd` command and many higher level interfaces including OpenStack.
-
-## Scope
-
-**TODO**
-
-## Backup
-
-To create a snapshot with `rbd`, specify the `snap create` option, the pool name and the 
-image name.
-
-````
-rbd --pool {pool-name} snap create --snap {snap-name} {image-name}
-rbd snap create {pool-name}/{image-name}@{snap-name}
-````
-
-For example:
-
-````
-rbd --pool rbd snap create --snap snapname foo
-rbd snap create rbd/foo@snapname
-````
-
-## Restore
-
-To rollback to a snapshot with `rbd`, specify the `snap rollback` option, the pool name, the 
-image name and the snap name.
-
-````
-rbd --pool {pool-name} snap rollback --snap {snap-name} {image-name}
-rbd snap rollback {pool-name}/{image-name}@{snap-name}
-````
-
-For example:
-
-````
-rbd --pool rbd snap rollback --snap snapname foo
-rbd snap rollback rbd/foo@snapname
-````
-
-**Note:** Rolling back an image to a snapshot means overwriting the current version of the image 
-with data from a snapshot. The time it takes to execute a rollback increases with the size of the 
-image. It is faster to clone from a snapshot than to rollback an image to a snapshot, and it is 
-the preferred method of returning to a pre-existing state.
-
-## Maintenance
-
-Taking snapshots increases your level of security but also costs disk space. To delete older ones
-you can list them, delete individual ones or purge all snapshots.
-
-To list snapshots of an image, specify the pool name and the image name.
-
-````
-rbd --pool {pool-name} snap ls {image-name}
-rbd snap ls {pool-name}/{image-name}
-````
-
-For example:
-
-````
-rbd --pool rbd snap ls foo
-rbd snap ls rbd/foo
-````
-
-To delete a snapshot with `rbd`, specify the `snap rm` option, the pool name, the image name 
-and the username.
-
-````
-rbd --pool {pool-name} snap rm --snap {snap-name} {image-name}
-rbd snap rm {pool-name}/{image-name}@{snap-name}
-````
-
-For example:
-
-````
-rbd --pool rbd snap rm --snap snapname foo
-rbd snap rm rbd/foo@snapname
-````
-
-**Note:** Ceph OSDs delete data asynchronously, so deleting a snapshot doesn’t free up the 
-disk space immediately.
-
-To delete all snapshots for an image with `rbd`, specify the snap purge option and the 
-image name.
-
-````
-rbd --pool {pool-name} snap purge {image-name}
-rbd snap purge {pool-name}/{image-name}
-````
-
-For example:
-
-````
-rbd --pool rbd snap purge foo
-rbd snap purge rbd/foo
-````
 
=== removed file 'Backup-and-Recovery-Juju.md'
--- Backup-and-Recovery-Juju.md	2014-04-02 16:18:10 +0000
+++ Backup-and-Recovery-Juju.md	1970-01-01 00:00:00 +0000
@@ -1,59 +0,0 @@
-Title: Backup and Recovery - Juju
-Status: In Progress
-
-# Backup and Recovery - Juju
-
-## Introduction
-
-**TODO**
-
-## Scope
-
-**TODO**
-
-## Backup
-
-Jujus working principle is based on storing the state of the cloud in
-database containing information about the environment, machines, services,
-and units. Changes to an environment are made to the state first, which are
-then detected by their according agents. Those are responsible to do the
-needed steps then.
-
-This principle allows Juju to easily do a *backup* of this information, plus
-some needed configuration data and some more useful information more. The 
-command to do so is `juju-backup`, which saves the currently selected 
-environment. So please make sure to switch to the environment you want to 
-backup.
-
-````
-$ juju switch my-env
-$ juju backup
-````
-
-The command creates two generations of backups on the bootstrap node, also
-know as `machine-0`. Beside the state and configuration data about this machine
-itself and the other ones of its environment the aggregated log for all
-machines and the one of this machine itself are saved. The aggregated log
-is the same you're accessing when calling
-
-````
-$ juju debug-log
-````
-
-and enables you to retrieve helpful information in case of a problem. After
-the backup is created on the bootstrap node it is transferred to your 
-working machine into the current directory as `juju-backup-YYYYMMDD-HHMM.tgz`,
-where *YYYYMMDD-HHMM* is date and time of the backup. In case you want to open 
-the backup manually to access the mentioned logging data you'll find it in the 
-contained archive `root.tar`. Here please don't wonder, this way all owner, 
-access rights and other information are preserved.
-
-## Restore
-
-To *restore* an environment the according command is 
-
-````
-$ juju restore <BACKUPFILE>
-````
-
-This way you're able to choose the concrete environment to restore.
 
=== removed file 'Backup-and-Recovery-OpenStack.md'
--- Backup-and-Recovery-OpenStack.md	2014-04-02 16:18:10 +0000
+++ Backup-and-Recovery-OpenStack.md	1970-01-01 00:00:00 +0000
@@ -1,131 +0,0 @@
-Title: Backup and Recovery - OpenStack
-Status: In Progress
-
-# Backup and Recovery - OpenStack
-
-## Introduction
-
-The OpenStack flexibility makes backup and restore to a very individual process
-depending on the used components. This section describes how the critical parts
-like the configuration files and databases OpenStack needs to run are saved. As
-before for Juju it doesn't describe ho to back up the objects inside the Object 
-Storage or the data inside the Block Storage.
-
-## Scope
-
-**TODO**
-
-## Backup Cloud Controller Database
-
-Like Juju the OpenStack cloud controller uses a database server which stores the
-central databases for Nova, Glance, Keystone, Cinder, and Switft. You can backup
-the five databases into one common dump:
-
-````
-$ mysqldump --opt --all-databases > openstack.sql
-````
-
-Alternatively you can backup the database for each component individually:
-
-````
-$ mysqldump --opt nova > nova.sql
-$ mysqldump --opt glance > glance.sql
-$ mysqldump --opt keystone > keystone.sql
-$ mysqldump --opt cinder > cinder.sql
-$ mysqldump --opt swift > swift.sql
-````
-
-## Backup File Systems
-
-Beside the databases OpenStack uses different directories for its configuration,
-runtime files, and logging. Like the databases they are grouped individually per
-component. This way also the backup can be done per component.
-
-### Nova
-
-You'll find the configuration directory `/etc/nova` on the cloud controller and 
-each compute node. It should be regularly backed up.
-
-Another directory to backup is `/var/lib/nova`. But here you have to be careful
-with the `instances` subdirectory on the compute nodes. It contains the KVM images
-of the running instances. If you want to maintain backup copies of those instances
-you can do a backup here too. In this case make sure to not save a live KVM instance
-because it may not boot properly after restoring the backup.
-
-Third directory for the compute component is `/var/log/nova`. In case of a central
-logging server this directory does not need to be backed up. So we suggest you to
-run your environment with this kind of logging.
-
-### Glance
-
-Like for Nova you'll find the directories `/etc/glance` and `/var/log/glance`, the
-handling should be the same here too.
-
-Glance also uses the directory named `/var/lib/glance` which also should be backed
-up.
-
-### Keystone
-
-Keystone is using the directories `/etc/keystone`, `/var/lib/keystone`, and
-`/var/log/keystone`. They follow the same rules as Nova and Glance. Even if
-the `lib` directory should not contain any data being used, can also be backed 
-up just in case.
-
-### Cinder
-
-Like before you'll find the directories `/etc/cinder`, `/var/log/cinder`,
-and `/var/lib/cinder`. And also here the handling should be the same. Opposite
-to Nova abd Glance there's no special handling of `/var/lib/cinder` needed.
-
-### Swift
-
-Beside the Swift configuration the directory `/etc/swift` contains the ring files
-and the ring builder files. If those get lest the data on your data gets inaccessable.
-So you can easily imagine how important it is to backup this directory. Best practise
-is to copy the builder files to the storage nodes along with the ring files. So
-multiple copies are spread throughout the cluster.
-
-**TODO(mue)** Really needed when we use Ceph for storage?
-
-## Restore
-
-The restore based on the backups is a step-by-step process restoring the components
-databases and all their directories. It's important that the component to restore is 
-currently not running. So always start the restoring with stopping all components.
-
-Let's take Nova as an example. First execute
-
-````
-$ stop nova-api
-$ stop nova-cert
-$ stop nova-consoleauth
-$ stop nova-novncproxy
-$ stop nova-objectstore
-$ stop nova-scheduler
-````
-
-on the cloud controller to savely stop the processes of the component. Next step is the
-restore of the database. By using the `--opt` option during backup we ensured that all
-tables are initially dropped and there's no conflict with currently existing data in
-the databases.
-
-````
-$ mysql nova < nova.sql
-````
-
-Before restoring the directories you should move at least the configuration directoy,
-here `/etc/nova`, into a secure location in case you need to roll it back.
-
-After the database and the files are restored you can start MySQL and Nova again.
-
-````
-$ start mysql
-$ start nova-api
-$ start nova-cert
-$ start nova-consoleauth
-$ start nova-novncproxy
-$ start nova-objectstore
-$ start nova-scheduler
-````
-
-The process for the other components look similar.
 
=== added directory 'Install'
=== added file 'Install/Installing-Ceph.md'
--- Install/Installing-Ceph.md	1970-01-01 00:00:00 +0000
+++ Install/Installing-Ceph.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,56 @@
+Title: Installing - Ceph
+Status: Review
+
+# Installing - Ceph
+
+## Introduction
+
+Typically OpenStack uses the local storage of their nodes for the configuration data
+as well as for the object storage provided by Swift and the block storage provided by 
+Cinder and Glance. But it also can use Ceph as storage backend. Ceph stripes block 
+device images across a cluster. This way it provides a better performance than typical 
+standalone server. It allows scalabillity and redundancy needs to be satisfied and 
+Cinder's RDB driver used to create, export and connect volumes to instances.
+
+## Scope
+
+This document covers the deployment of Ceph via Juju. Other related documents are
+
+- [Scaling Ceph](Scaling-Ceph.md)
+- [Troubleshooting Ceph](Troubleshooting-Ceph.md)
+- [Appendix Ceph and OpenStack](Appendix-Ceph-and-OpenStack.md)
+
+## Deployment
+
+During the installation of OpenStack we've already seen the deployment of Ceph via
+
+```
+juju deploy --config openstack-config.yaml -n 3 ceph
+juju deploy --config openstack-config.yaml -n 10 ceph-osd
+```
+
+This will install three Ceph nodes configured with the information contained in the
+file `openstack-config.yaml`. This file contains the configuration `block-device: None`
+for Cinder, so that this component does not use the local disk. Instead we're calling
+Additionally 10 Ceph OSD nodes providing the object storage are deployed and related 
+to the Ceph nodes by
+
+```
+juju add-relation ceph-osd ceph
+```
+
+Once the ceph charm has bootstrapped the cluster, it will notify the ceph-osd charm which 
+will scan for the configured storage devices and add them to the pool of available storage.
+Now the relation to Cinder and Glance can be established with
+
+```
+juju add-relation cinder ceph
+juju add-relation glance ceph
+```
+
+so that both are using the storage provided by Ceph.
+
+## See also
+
+- https://manage.jujucharms.com/charms/precise/ceph
+- https://manage.jujucharms.com/charms/precise/ceph-osd
 
=== added file 'Install/Installing-MAAS.md'
--- Install/Installing-MAAS.md	1970-01-01 00:00:00 +0000
+++ Install/Installing-MAAS.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,467 @@
+Title: Installing MAAS 
+Status: In progress
+Notes:
+
+
+
+
+
+#Installing the MAAS software
+
+##Scope of this documentation
+
+This document provides instructions on how to install the Metal As A Service (MAAS) software. It has been prepared alongside guides for installing Juju, OpenStack and Landscape as part of a production grade cloud environment. MAAS itself may be used in different ways and you can find documentation for this on the main MAAS website [MAAS docs]. For the purposes of this documentation, the following assumptions have been made:
+* You have sufficient, appropriate node hardware 
+* You will be using Juju to assign workloads to MAAS
+* You will be configuring the cluster network to be controlled entirely by MAAS (i.e. DNS and DHCP)
+* If you have a compatible power-management system, any additional hardware required is also installed(e.g. IPMI network).
+
+## Introducing MAAS
+
+Metal as a Service – MAAS – lets you treat physical servers like virtual machines in the cloud. Rather than having to manage each server individually, MAAS turns your bare metal into an elastic cloud-like resource.
+
+What does that mean in practice? Tell MAAS about the machines you want it to manage and it will boot them, check the hardware’s okay, and have them waiting for when you need them. You can then pull nodes up, tear them down and redeploy them at will; just as you can with virtual machines in the cloud.
+
+When you’re ready to deploy a service, MAAS gives Juju the nodes it needs to power that service. It’s as simple as that: no need to manually provision, check and, afterwards, clean-up. As your needs change, you can easily scale services up or down. Need more power for your Hadoop cluster for a few hours? Simply tear down one of your Nova compute nodes and redeploy it to Hadoop. When you’re done, it’s just as easy to give the node back to Nova.
+
+MAAS is ideal where you want the flexibility of the cloud, and the hassle-free power of Juju charms, but you need to deploy to bare metal.
+
+## Installing MAAS from the Cloud Archive
+
+The Ubuntu Cloud Archive is a repository made especially to provide users with the most up to date, stable versions of MAAS, Juju and other tools. It is highly recommended to configure this repository and use it to keep your software up to date:
+
+```
+sudo add-apt-repository cloud-archive:tools
+sudo apt-get update
+```
+
+There are several packages that comprise a MAAS install. These are:
+
+maas-region-controller:
+    Which comprises the 'control' part of the software, including the web-based user interface, the API server and the main database.
+maas-cluster-controller:
+    This includes the software required to manage a cluster of nodes, including managing DHCP and boot images.
+maas-dns:
+    This is a customised DNS service that MAAS can use locally to manage DNS for all the connected nodes.
+mass-dhcp:
+    As for DNS, there is a DHCP service to enable MAAS to correctly enlist nodes and assign IP addresses. The DHCP setup is critical for the correct PXE booting of nodes.
+
+As a convenience, there is also a `maas` metapackage, which will install all these components
+
+
+If you need to separate these services or want to deploy an additional cluster controller, you should install the corresponding packages individually (see [_the description of a typical setup_](https://www.filepicker.io/api/file/orientation.html#setup) for more background on how a typical hardware setup might be arranged).
+
+
+
+
+### Installing the packages
+
+The configuration for the MAAS controller will automatically run and pop up this config screen:
+
+![]( install_cluster-config.png)
+
+Here you will need to enter the hostname for where the region controller can be contacted. In many scenarios, you may be running the region controller (i.e. the web and API interface) from a different network address, for example where a server has several network interfaces.
+
+Once the configuration scripts have run you should see this message telling you that the system is ready to use:
+
+![]( install_controller-config.png)
+
+The web server is started last, so you have to accept this message before the service is run and you can access the Web interface. Then there are just a few more setup steps [_Post-Install tasks_](https://www.filepicker.io/api/file/WMGTttJT6aaLnQrEkAPv?signature=a86d0c3b4e25dba2d34633bbdc6873d9d8e6ae3cecc4672f2219fa81ee478502&policy=eyJoYW5kbGUiOiJXTUdUdHRKVDZhYUxuUXJFa0FQdiIsImV4cGlyeSI6MTM5NTE3NDE2MSwiY2FsbCI6WyJyZWFkIl19#post-install)
+
+The maas-dhcp and maas-dns packages should be installed by default. You can check whether they are installed with:
+
+```
+dpkg -l maas-dhcp maas-dns
+```
+
+If they are missing, then:
+
+```
+sudo apt-get install maas-dhcp maas-dns
+```
+
+And then proceed to the post-install setup below.
+
+If you now use a web browser to connect to the region controller, you should see that MAAS is running, but there will also be some errors on the screen:
+
+![]( install_web-init.png)
+
+The on screen messages will tell you that there are no boot images present, and that you can't login because there is no admin user.
+
+## Create a superuser account
+
+Once MAAS is installed, you'll need to create an administrator account:
+
+```
+sudo maas createadmin --username=root --email=[e-mail]
+```
+
+Substitute your own email address in the command above. You may also use a different username for your administrator account, but "root" is a common convention and easy to remember. The command will prompt for a password to assign to the new user.
+
+You can run this command again for any further administrator accounts you may wish to create, but you need at least one.
+
+## Import the boot images
+
+MAAS will check for and download new Ubuntu images once a week. However, you'll need to download them manually the first time. To do this you will need to connect to the MAAS API using the maas-cli tool. (see for details). Then you need to run the command:
+
+```
+maas-cli maas node-groups import-boot-images
+```
+
+(substitute in a different profile name for 'maas' if you have called yours something else) This will initiate downloading the required image files. Note that this may take some time depending on your network connection.
+
+
+## Login to the server
+
+To check that everything is working properly, you should try and login to the server now. Both the error messages should have gone (it can take a few minutes for the boot image files to register) and you can see that there are currently 0 nodes attached to this controller.
+
+![]( install-login.png)
+## Configure switches on the network
+
+Some switches use Spanning-Tree Protocol (STP) to negotiate a loop-free path through a root bridge. While scanning, it can make each port wait up to 50 seconds before data is allowed to be sent on the port. This delay in turn can cause problems with some applications/protocols such as PXE, DHCP and DNS, of which MAAS makes extensive use.
+
+To alleviate this problem, you should enable [Portfast](https://www.symantec.com/business/support/index?page=content&id=HOWTO6019) for Cisco switches or its equivalent on other vendor equipment, which enables the ports to come up almost immediately.
+
+##Add an additional cluster
+
+Whilst it is certainly possible to run MAAS with just one cluster controller for all the nodes, in the interests of easier maintenance, uprades and stability, it is desirable to have at least two operational clusters.
+
+Each cluster needs a controller node. Install Ubuntu on this node and then follow a similar setup proceedure to install the cluster controller software:
+
+```
+sudo add-apt-repository cloud-archive:tools
+sudo apt-get update
+sudo apt-get install maas-cluster-controller
+sudo apt-get install maas-dhcp
+```
+
+During the install process, a configuration window will appear. You merely need to type in the address of the MAAS controller API, like this:
+
+![config-image.png]
+
+## Configure Cluster Controller(s)
+
+### Cluster acceptance
+When you install your first cluster controller on the same system as the region controller, it will be automatically accepted by default (but not yet configured, see below). Any other cluster controllers you set up will show up in the user interface as “pending,” until you manually accept them into the MAAS.
+
+To accept a cluster controller, click on the settings “cog” icon at the top right to visit the settings page:
+![]settings.png
+You can either click on “Accept all” or click on the edit icon to edit the cluster. After clicking on the edit icon, you will see this page:
+
+![]cluster-edit.png
+Here you can change the cluster’s name as it appears in the UI, its DNS zone, and its status. Accepting the cluster changes its status from “pending” to “accepted.”
+
+Now that the cluster controller is accepted, you can configure one or more of its network interfaces to be managed by MAAS. This will enable the cluster controller to manage nodes attached to those networks. The next section explains how to do this and what choices are to be made.
+
+### Configuration
+MAAS automatically recognises the network interfaces on each cluster controller. Some of these will be connected to networks where you want to manage nodes. We recommend letting your cluster controller act as a DHCP server for these networks, by configuring those interfaces in the MAAS user interface.
+
+As an example, we will configure the cluster controller to manage a network on interface eth0. Click on the edit icon for eth0, which takes us to this page:
+
+![]cluster-interface-edit.png
+Here you can select to what extent you want the cluster controller to manage the network:
+
+DHCP only - this will run a DHCP server on your cluster
+DHCP and DNS - this will run a DHCP server on the cluster and configure the DNS server included with the region controller so that it can be used to look up hosts on this network by name.
+Note
+You cannot have DNS management without DHCP management because MAAS relies on its own DHCP server’s leases file to work out the IP address of nodes in the cluster.
+If you set the interface to be managed, you now need to provide all of the usual DHCP details in the input fields below. Once done, click “Save interface”. The cluster controller will now be able to boot nodes on this network.
+
+!!! note:There is also an option to leave the network unmanaged. Use this for networks where you don’t want to manage any nodes. Or, if you do want to manage nodes but don’t want the cluster controller to serve DHCP, you may be able to get by without it. This is explained in Manual DHCP configuration.
+
+!!! note: A single cluster controller can manage more than one network, each from a different network interface on the cluster-controller server. This may help you scale your cluster to larger numbers of nodes, or it may be a requirement of your network architecture.
+
+## Enlisting nodes
+
+Now that the MAAS controller is running, we need to make the nodes aware of MAAS and vice-versa. With MAAS controlling DHCP and nodes capable of PXE booting, this is straightforward
+
+Automatic Discovery
+With nodes set to boot from a PXE image, they will start, look for a DHCP server, receive the PXE boot details, boot the image, contact the MAAS server and shut down.
+
+During this process, the MAAS server will be passed information about the node, including the architecture, MAC address and other details which will be stored in the database of nodes. You can accept and comission the nodes via the web interface. When the nodes have been accepted the selected series of Ubuntu will be installed.
+
+To save time, you can also accept and commission all nodes from the commandline. This requires that you first login with the API key [1], which you can retrieve from the web interface:
+
+```
+maas-cli maas nodes accept-all
+```
+
+### Manually adding nodes
+
+If your nodes are not capable of booting from PXE images, they can be manually registered with MAAS. On the Nodes screen:
+![]add-node.png
+
+Select 'Add node' and manually enter details about the node, including its MAC address. This is used to identify the node when it contacts the DHCP server.
+
+
+
+## Preparing MAAS for Juju using Simplestreams
+
+When Juju bootstraps a cloud, it needs two critical pieces of information:
+
+1. The uuid of the image to use when starting new compute instances.
+2. The URL from which to download the correct version of a tools tarball.
+
+This necessary information is stored in a json metadata format called "simplestreams". For supported public cloud services such as Amazon Web Services, HP Cloud, Azure, etc, no action is required by the end user. However, those setting up a private cloud, or who want to change how things work (eg use a different Ubuntu image), can create their own metadata, after understanding a bit about how it works.
+
+The simplestreams format is used to describe related items in a structural fashion.( [See the Launchpad project lp:simplestreams for more details on implementation](https://launchpad.net/simplestreams)). Below we will discuss how Juju determines which metadata to use, and how to create your own images and tools and have Juju use them instead of the defaults.
+
+### Basic Workflow
+
+Whether images or tools, Juju uses a search path to try and find suitable metadata. The path components (in order of lookup) are:
+
+1. User supplied location (specified by tools-metadata-url or image-metadata-url config settings).
+2. The environment's cloud storage.
+3. Provider specific locations (eg keystone endpoint if on Openstack).
+4. A web location with metadata for supported public clouds (https://streams.canonical.com).
+
+Metadata may be inline signed, or unsigned. We indicate a metadata file is signed by using the '.sjson' extension. Each location in the path is first searched for signed metadata, and if none is found, unsigned metadata is attempted before moving onto the next path location.
+
+Juju ships with public keys used to validate the integrity of image and tools metadata obtained from https://streams.canonical.com. So out of the box, Juju will "Just Work" with any supported public cloud, using signed metadata. Setting up metadata for a private (eg Openstack) cloud requires metadata to be generated using tools which ship with Juju.
+
+### Image Metadata Contents
+
+Image metadata uses a simplestreams content type of "image-ids". The product id is formed as follows:
+
+com.ubuntu.cloud:server:<series_version>:<arch> For Example:
+com.ubuntu.cloud:server:14.04:amd64 Non-released images (eg beta, daily etc) have product ids like:
+com.ubuntu.cloud.daily:server:13.10:amd64
+
+The metadata index and product files are required to be in the following directory tree (relative to the URL associated with each path component):
+
+<path_url> |-streams |-v1 |-index.(s)json |-product-foo.(s)json |-product-bar.(s)json
+
+The index file must be called "index.(s)json" (sjson for signed). The various product files are named according to the Path values contained in the index file.
+
+Tools metadata uses a simplestreams content type of "content-download". The product id is formed as follows:
+
+"com.ubuntu.juju:<series_version>:<arch>"
+
+For example:
+
+"com.ubuntu.juju:12.04:amd64"
+
+The metadata index and product files are required to be in the following directory tree (relative to the URL associated with each path component). In addition, tools tarballs which Juju needs to download are also expected.
+
+|-streams | |-v1 | |-index.(s)json | |-product-foo.(s)json | |-product-bar.(s)json | |-releases |-tools-abc.tar.gz |-tools-def.tar.gz |-tools-xyz.tar.gz
+
+The index file must be called "index.(s)json" (sjson for signed). The product file and tools tarball name(s) match whatever is in the index/product files.
+
+### Configuration
+
+For supported public clouds, no extra configuration is required; things work out-of-the-box. However, for testing purposes, or for non-supported cloud deployments, Juju needs to know where to find the tools and which image to run. Even for supported public clouds where all required metadata is available, the user can put their own metadata in the search path to override what is provided by the cloud.
+
+#### User specified URLs
+
+These are initially specified in the environments.yaml file (and then subsequently copied to the jenv file when the environment is bootstrapped). For images, use "image-metadata-url"; for tools, use "tools-metadata-url". The URLs can point to a world readable container/bucket in the cloud, an address served by a http server, or even a shared directory which is accessible by all node instances running in the cloud.
+
+Assume an Apache http server with base URL `https://juju-metadata` , providing access to information at `<base>/images` and `<base>/tools` . The Juju environment yaml file could have the following entries (one or both):
+
+tools-metadata-url: https://juju-metadata/tools image-metadata-url: https://juju-metadata/images
+
+The required files in each location is as per the directory layout described earlier. For a shared directory, use a URL of the form "file:///sharedpath".
+
+#### Cloud storage
+
+If no matching metadata is found in the user specified URL, environment's cloud storage is searched. No user configuration is required here - all Juju environments are set up with cloud storage which is used to store state information, charms etc. Cloud storage setup is provider dependent; for Amazon and Openstack clouds, the storage is defined by the "control-bucket" value, for Azure, the "storage-account-name" value is relevant.
+
+The (optional) directory structure inside the cloud storage is as follows:
+
+|-tools | |-streams | |-v1 | |-releases | |-images |-streams |-v1
+
+Of course, if only custom image metadata is required, the tools directory will not be required, and vice versa.
+
+Note that if juju bootstrap is run with the `--upload-tools` option, the tools and metadata are placed according to the above structure. That's why the tools are then available for Juju to use.
+
+#### Provider specific storage
+
+Providers may allow additional locations to search for metadata and tools. For OpenStack, Keystone endpoints may be created by the cloud administrator. These are defined as follows:
+
+juju-tools the &LT;path_url&GT; value as described above in Tools Metadata Contentsproduct-streams the &LT;path_url&GT; value as described above in Image Metadata Contents
+
+Other providers may similarly be able to specify locations, though the implementation will vary.
+
+This is the default location used to search for image and tools metadata and is used if no matches are found earlier in any of the above locations. No user configuration is required.
+
+There are two main issues when deploying a private cloud:
+
+1. Image ids will be specific to the cloud.
+2. Often, outside internet access is blocked
+
+Issue 1 means that image id metadata needs to be generated and made available.
+
+Issue 2 means that tools need to be mirrored locally to make them accessible.
+
+Juju tools exist to help with generating and validating image and tools metadata. For tools, it is often easiest to just mirror `https://streams.canonical.com/tools` . However image metadata cannot be simply mirrored because the image ids are taken from the cloud storage provider, so this needs to be generated and validated using the commands described below.
+
+The available Juju metadata tools can be seen by using the help command:
+
+juju help metadata
+
+The overall workflow is:
+
+- Generate image metadata
+- Copy image metadata to somewhere in the metadata search path
+- Optionally, mirror tools to somewhere in the metadata search path
+- Optionally, configure tools-metadata-url and/or image-metadata-url
+
+#### Image metadata
+
+Generate image metadata using
+
+juju metadata generate-image -d <metadata_dir>
+
+As a minimum, the above command needs to know the image id to use and a directory in which to write the files.
+
+Other required parameters like region, series, architecture etc. are taken from the current Juju environment (or an environment specified with the -e option). These parameters can also be overridden on the command line.
+
+The image metadata command can be run multiple times with different regions, series, architecture, and it will keep adding to the metadata files. Once all required image ids have been added, the index and product json files can be uploaded to a location in the Juju metadata search path. As per the Configuration section, this may be somewhere specified by the `image-metadata-url` setting or the cloud's storage etc.
+
+Examples:
+
+1. image-metadata-url
+
+- upload contents of to `http://somelocation`
+- set image-metadata-url to `http://somelocation/images`
+
+2. Cloud storage
+
+If run without parameters, the validation command will take all required details from the current Juju environment (or as specified by -e) and output the image id it would use to spin up an instance. Alternatively, series, region, architecture etc. can be specified on the command line to override the values in the environment config.
+#### Tools metadata
+
+Generally, tools and related metadata are mirrored from `https://streams.canonical.com/tools` . However, it is possible to manually generate metadata for a custom built tools tarball.
+
+First, create a tarball of the relevant tools and place in a directory structured like this:
+
+<tools_dir>/tools/releases/
+
+Now generate relevant metadata for the tools by running the command:
+
+juju generate-tools -d <tools_dir>
+
+Finally, the contents of can be uploaded to a location in the Juju metadata search path. As per the Configuration section, this may be somewhere specified by the tools-metadata-url setting or the cloud's storage path settings etc.
+
+Examples:
+
+1. tools-metadata-url
+
+- upload contents of the tools dir to `http://somelocation`
+- set tools-metadata-url to `http://somelocation/tools`
+
+2. Cloud storage
+
+upload contents of directly to environment's cloud storage
+
+As with image metadata, the validation command is used to ensure tools are available for Juju to use:
+
+juju metadata validate-tools
+
+The same comments apply. Run the validation tool without parameters to use details from the Juju environment, or override values as required on the command line. See `juju help metadata validate-tools` for more details.
+
+##Appendix I - Using Tags
+##Appendix II - Using the MAAS CLI
+As well as the web interface, many tasks can be performed by accessing the MAAS API directly through the maas-cli command. This section details how to login with this tool and perform some common operations.
+
+###Logging in
+Before the API will accept any commands from maas-cli, you must first login. To do this, you need the API key which can be found in the user interface.
+
+Login to the web interface on your MAAS. Click on the username in the top right corner and select ‘Preferences’ from the menu which appears.
+
+![]maascli-prefs.png
+A new page will load...
+
+![]maascli-key.png
+The very first item is a list of MAAS keys. One will have already been generated when the system was installed. It’s easiest to just select all the text, copy the key (it’s quite long!) and then paste it into the commandline. The format of the login command is:
+
+```
+ maas-cli login <profile-name> <hostname> <key>
+```
+
+The profile created is an easy way of associating your credentials with any subsequent call to the API. So an example login might look like this:
+
+```
+maas-cli login maas http://10.98.0.13/MAAS/api/1.0
+AWSCRMzqMNy:jjk...5e1FenoP82Qm5te2
+```
+which creates the profile ‘maas’ and registers it with the given key at the specified API endpoint. If you omit the credentials, they will be prompted for in the console. It is also possible to use a hyphen, ‘-‘ in place of the credentials. In this case a single line will be read from stdin, stripped of any whitespace and used as the credentials, which can be useful if you are devolping scripts for specific tasks. If an empty string is passed instead of the credentials, the profile will be logged in anonymously (and consequently some of the API calls will not be available)
+
+### maas-cli commands
+The maas-cli command exposes the whole API, so you can do anything you actually can do with MAAS using this command. This leaves us with a vast number of options, which are more fully expressed in the complete [2][MAAS Documentation]
+
+list:
+    lists the details [name url auth-key] of all the currently logged-in profiles.
+
+login <profile> <url> <key>:
+    Logs in to the MAAS controller API at the given URL, using the key provided and
+    associates this connection with the given profile name.
+
+logout <profile>:
+    Logs out from the given profile, flushing the stored credentials.
+
+refresh:
+    Refreshes the API descriptions of all the current logged in profiles. This may become necessary for example when upgrading the maas packages to ensure the command-line options match with the API.
+
+### Useful examples
+
+Displays current status of nodes in the commissioning phase:
+```
+maas cli maas nodes check-commissioning
+```
+
+Accept and commission all discovered nodes:
+```
+maas-cli maas nodes accept-all
+```
+
+List all known nodes:
+```
+maas-cli maas nodes list
+```
+
+Filter the list using specific key/value pairs:
+```
+maas-cli maas nodes list architecture="i386/generic"
+```
+
+Set the power parameters for an ipmi enabled node:
+```
+maas-cli maas node update <system_id> \
+  power_type="ipmi" \
+  power_parameters_power_address=192.168.22.33 \
+  power_parameters_power_user=root \
+  power_parameters_power_pass=ubuntu;
+```
+## Appendix III - Physical Zones
+
+To help you maximise fault-tolerance and performance of the services you deploy, MAAS administrators can define _physical zones_ (or just _zones_ for short), and assign nodes to them. When a user requests a node, they can ask for one that is in a specific zone, or one that is not in a specific zone.
+
+It's up to you as an administrator to decide what a physical zone should represent: it could be a server rack, a room, a data centre, machines attached to the same UPS, or a portion of your network. Zones are most useful when they represent portions of your infrastructure. But you could also use them simply to keep track of where your systems are located.
+
+Each node is in one and only one physical zone. Each MAAS instance ships with a default zone to which nodes are attached by default. If you do not need this feature, you can simply pretend it does not exist.
+
+### Applications
+
+Since you run your own MAAS, its physical zones give you more flexibility than those of a third-party hosted cloud service. That means that you get to design your zones and define what they mean. Below are some examples of how physical zones can help you get the most out of your MAAS.
+
+### Creating a Zone
+
+Only administrators can create and manage zones. To create a physical zone in the web user interface, log in as an administrator and browse to the "Zones" section in the top bar. This will takes you to the zones listing page. At the bottom of the page is a button for creating a new zone:
+
+![]add-zone.png
+
+Or to do it in the [_region-controller API_][#region-controller-api], POST your zone definition to the _"zones"_ endpoint.
+
+### Assigning Nodes to a Zone
+
+Once you have created one or more physical zones, you can set nodes' zones from the nodes listing page in the UI. Select the nodes for which you wish to set a zone, and choose "Set physical zone" from the "Bulk action" dropdown list near the top. A second dropdown list will appear, to let you select which zone you wish to set. Leave it blank to clear nodes' physical zones. Clicking "Go" will apply the change to the selected nodes.
+
+You can also set an individual node's zone on its "Edit node" page. Both ways are available in the API as well: edit an individual node through a request to the node's URI, or set the zone on multiple nodes at once by calling the operation on the endpoint.
+
+### Allocating a Node in a Zone
+
+To deploy in a particular zone, call the method in the [_region-controller API_][#region-controller-api] as before, but pass the parameter with the name of the zone. The method will allocate a node in that zone, or fail with an HTTP 409 ("conflict") error if the zone has no nodes available that match your request.
+
+Alternatively, you may want to request a node that is _not_ in a particular zone, or one that is not in any of several zones. To do that, specify the parameter to . This parameter takes a list of zone names; the allocated node will not be in any of them. Again, if that leaves no nodes available that match your request, the call will return a "conflict" error.
+
+It is possible, though not usually useful, to combine the and parameters. If your choice for is also present in , no node will ever match your request. Or if it's not, then the values will not affect the result of the call at all.
+
 
=== added file 'Install/Intro.md'
--- Install/Intro.md	1970-01-01 00:00:00 +0000
+++ Install/Intro.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,28 @@
+Title: Introduction
+
+#Ubuntu Cloud Documentation
+
+## Deploying Production Grade OpenStack with MAAS, Juju and Landscape
+
+This documentation has been created to describe best practice in deploying
+a Production Grade installation of OpenStack using current Canonical 
+technologies, including bare metal provisioning using MAAS, service 
+orchestration with Juju and system management with Landscape.
+
+This documentation is divided into four main topics:
+
+ 1. [Installing the MAAS Metal As A Service software](../installing-maas.html)
+ 2. [Installing Juju and configuring it to work with MAAS](../installing-juju.html)
+ 3. [Using Juju to deploy OpenStack](../installing-openstack.html)
+ 4. [Deploying Landscape to manage your OpenStack cloud](../installing-landscape)
+ 
+Once you have an up and running OpenStack deployment, you should also read
+our [Administration Guide](../admin-intro.html) which details common tasks
+for maintenance and scaling of your service. 
+
+
+## Legal notices
+
+
+
+![Canonical logo](./media/logo-canonical_no™-aubergine-hex.jpg)
 
=== added file 'Install/installing-openstack-outline.md'
--- Install/installing-openstack-outline.md	1970-01-01 00:00:00 +0000
+++ Install/installing-openstack-outline.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,395 @@
+Title:Installing OpenStack
+
+# Installing OpenStack
+
+![Openstack](../media/openstack.png)
+
+##Introduction
+
+OpenStack is a versatile, open source cloud environment equally suited to serving up public, private or hybrid clouds. Canonical is a Platinum Member of the OpenStack foundation and has been involved with the OpenStack project since its inception; the software covered in this document has been developed with the intention of providing a streamlined way to deploy and manage OpenStack installations.
+
+### Scope of this documentation
+
+The OpenStack platform is powerful and its uses diverse. This section of documentation 
+is primarily concerned with deploying a 'standard' running OpenStack system using, but not limited to, Canonical components such as MAAS, Juju and Ubuntu. Where appropriate other methods and software will be mentioned.
+
+### Assumptions
+
+1. Use of MAAS
+   This document is written to provide instructions on how to deploy OpenStack using MAAS for hardware provisioning. If you are not deploying directly on hardware, this method will still work, with a few alterations, assuming you have a properly configured Juju environment. The main difference will be that you will have to provide different configuration options depending on the network configuration.
+   
+2. Use of Juju
+   This document assumes an up to date, stable release version of Juju.
+   
+3. Local network configuration
+   This document assumes that you have an adequate local network configuration, including separate interfaces for access to the OpenStack cloud. Ideal networks are laid out in the [MAAS][MAAS documentation for OpenStack]
+
+## Planning an installation
+
+Before deploying any services, it is very useful to take stock of the resources available and how they are to be used. OpenStack comprises of a number of interrelated services (Nova, Swift, etc) which each have differing demands in terms of hosts. For example, the Swift service, which provides object storage, has a different requirement than the Nova service, which provides compute resources.
+
+The minimum requirements for each service and recommendations are laid out in the official [oog][OpenStack Operations Guide] which is available (free) in HTML or various downloadable formats. For guidance, the following minimums are recommended for Ubuntu Cloud:
+
+[insert minimum hardware spec]
+
+
+
+The recommended composition of nodes for deploying OpenStack with MAAS and Juju is that all nodes in the system should be capable of running *ANY* of the services. This is best practice for the robustness of the system, as since any physical node should fail, another can be repurposed to take its place. This obviously extends to any hardware requirements such as extra network interfaces.
+
+If for reasons of economy or otherwise you choose to use different configurations of hardware, you should note that your ability to overcome hardware failure will be reduced. It will also be necessary to target deployments to specific nodes - see the section in the MAAS documentation on tags [MAAS tags]
+
+
+###Create the OpenStack configuration file
+
+We will be using Juju charms to deploy the component parts of OpenStack. Each charm encapsulates everything required to set up a particular service. However, the individual services have many configuration options, some of which we will want to change. 
+
+To make this task easier and more reproduceable, we will create a separate configuration file with the relevant options for all the services. This is written in a standard YAML format. 
+
+You can download the [openstack-config.yaml] file we will be using from here. It is also reproduced below:
+
+```
+keystone:
+  admin-password: openstack
+  debug: 'true'
+  log-level: DEBUG
+nova-cloud-controller:
+  network-manager: 'Neutron'
+  quantum-security-groups: 'yes'
+  neutron-external-network: Public_Network
+nova-compute:
+  enable-live-migration: 'True'
+  migration-auth-type: "none"
+  virt-type: kvm
+  #virt-type: lxc
+  enable-resize: 'True'
+quantum-gateway:
+  ext-port: 'eth1'
+  plugin: ovs
+glance:
+  ceph-osd-replication-count: 3
+cinder:
+  block-device: None
+  ceph-osd-replication-count: 3
+  overwrite: "true"
+  glance-api-version: 2
+ceph:
+  fsid: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
+  monitor-secret: AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==
+  osd-devices: /dev/sdb
+  osd-reformat: 'True'
+```
+
+For all services, we can configure the `openstack-origin` to point to an install source. In this case, we will rely on the default, which will point to the relevant sources for the Ubuntu 14.04 LTS Trusty release. Further configuration for each service is explained below:
+
+####keystone
+admin password:
+    You should set a memorable password here to be able to access OpenStack when it is deployed
+
+debug: 
+    It is useful to set this to 'true' initially, to monitor the setup. this will produce more verbose messaging.
+   
+log-level: 
+    Similarly, setting the log-level to DEBUG means that more verbose logs can be generated. These options can be changed once the system is set up and running normally. 
+
+####nova-cloud-controller
+
+cloud-controller:
+    'Neutron' - Other options are now depricated.
+    
+quantum-security-groups: 
+    'yes'
+    
+neutron-external-network: 
+    Public_Network - This is an interface we will use for allowing access to the cloud, and will be defined later
+
+####nova-compute
+enable-live-migration: 
+  We have set this to 'True'
+
+migration-auth-type: 
+    "none"
+
+virt-type: 
+    kvm
+
+enable-resize: 
+    'True'
+
+####quantum-gateway
+ext-port:
+    This is where we specify the hardware for the public network. Use 'eth1' or the relevant 
+  plugin: ovs
+  
+  
+####glance
+
+  ceph-osd-replication-count: 3
+
+####cinder
+  openstack-origin: cloud:trusty-icehouse/updates
+  block-device: None
+  ceph-osd-replication-count: 3
+  overwrite: "true"
+  glance-api-version: 2
+  
+####ceph
+  
+fsid: 
+    The fsid is simply a unique identifier. You can generate a suitable value by running `uuidgen`  which should return a value which looks like: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
+    
+monitor-secret: 
+    The monitor secret is a secret string used to authenticate access. There is advice on how to generate a suitable secure secret at [ceph][the ceph website]. A typical value would be `AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==`
+    
+osd-devices: 
+    This should point (in order of preference) to a device,partition or filename. In this case we will assume secondary device level storage located at `/dev/sdb`
+    
+osd-reformat: 
+    We will set this to 'True', allowing ceph to reformat the drive on provisioning. 
+    
+  
+##Deploying OpenStack with Juju
+Now that the configuration is defined, we can use Juju to deploy and relate the services.
+
+###Initialising Juju
+Juju requires a minimal amount of setup. Here we assume it has already been configured to work with your MAAS cluster (see the [juju_install][Juju Install Guide] for more information on this.
+
+Firstly, we need to fetch images and tools that Juju will use:
+```
+juju sync-tools --debug
+```
+Then we can create the bootstrap instance:
+
+```
+juju bootstrap --upload-tools --debug
+```
+We use the upload-tools switch to use the local versions of the tools which we just fetched. The debug switch will give verbose output which can be useful. This process may take a few minutes, as Juju is creating an instance and installing the tools. When it has finished, you can check the status of the system with the command:
+```
+juju status
+```
+This should return something like:
+```
+---------- example 
+```
+### Deploy the OpenStack Charms
+
+Now that the Juju bootstrap node is up and running we can deploy the services required to make our OpenStack installation. To configure these services properly as they are deployed, we will make use of the configuration file we defined earlier, by passing it along with the `--config` switch with each deploy command. Substitute in the name and path of your config file if different.
+
+It is useful but not essential to deploy the services in the order below. It is also highly reccommended to open an additional terminal window and run the command `juju debug-log`. This will output the logs of all the services as they run, and can be useful for troubleshooting.
+
+It is also recommended to run a `juju status` command periodically, to check that each service has been installed and is running properly. If you see any errors, please consult the [troubleshooting][troubleshooting section below].
+
+```
+juju deploy --to=0 juju-gui
+juju deploy rabbitmq-server
+juju deploy mysql
+juju deploy --config openstack-config.yaml openstack-dashboard
+juju deploy --config openstack-config.yaml keystone
+juju deploy --config openstack-config.yaml ceph -n 3
+juju deploy --config openstack-config.yaml nova-compute -n 3
+juju deploy --config openstack-config.yaml quantum-gateway
+juju deploy --config openstack-config.yaml cinder
+juju deploy --config openstack-config.yaml nova-cloud-controller
+juju deploy --config openstack-config.yaml glance
+juju deploy --config openstack-config.yaml ceph-radosgw
+```
+
+
+### Add relations between the OpenStack services
+
+Although the services are now deployed, they are not yet connected together. Each service currently exists in isolation. We use the `juju add-relation`command to make them aware of each other and set up any relevant connections and protocols. This extra configuration is taken care of by the individual charms themselves. 
+
+    
+We should start adding relations between charms by setting up the Keystone authorization service and its database, as this will be needed by many of the other connections:
+
+juju add-relation keystone mysql
+
+We wait until the relation is set. After it finishes check it with juju status:
+
+```
+juju status mysql
+juju status keystone
+```
+
+It can take a few moments for this service to settle. Although it is certainly possible to continue adding relations (Juju manages a queue for pending actions) it can be counterproductive in terms of the overall time taken, as many of the relations refer to the same services.
+The following relations also need to be made:
+```
+juju add-relation nova-cloud-controller mysql
+juju add-relation nova-cloud-controller rabbitmq-server
+juju add-relation nova-cloud-controller glance
+juju add-relation nova-cloud-controller keystone
+juju add-relation nova-compute mysql
+juju add-relation nova-compute rabbitmq-server
+juju add-relation nova-compute glance
+juju add-relation nova-compute nova-cloud-controller
+juju add-relation glance mysql
+juju add-relation glance keystone
+juju add-relation cinder keystone
+juju add-relation cinder mysql
+juju add-relation cinder rabbitmq-server
+juju add-relation cinder nova-cloud-controller
+juju add-relation openstack-dashboard keystone
+juju add-relation swift-proxy swift-storage
+juju add-relation swift-proxy keystone
+```
+Finally, the output of juju status should show the all the relations as complete. The OpenStack cloud is now running, but it needs to be populated with some additional components before it is ready for use.
+
+
+
+
+##Preparing OpenStack for use
+
+###Configuring access to Openstack
+
+
+
+The configuration data for OpenStack can be fetched by reading the configuration file generated by the Keystone service. You can also copy this information by logging in to the Horizon (OpenStack Dashboard) service and examining the configuration there. However, we actually need only a few bits of information. The following bash script can be run to extract the relevant information:
+
+```
+#!/bin/bash
+
+set -e
+
+KEYSTONE_IP=`juju status keystone/0 | grep public-address | awk '{ print $2 }' | xargs host | grep -v alias | awk '{ print $4 }'`
+KEYSTONE_ADMIN_TOKEN=`juju ssh keystone/0 "sudo cat /etc/keystone/keystone.conf | grep admin_token" | sed -e '/^M/d' -e 's/.$//' | awk '{ print $3 }'`
+
+echo "Keystone IP: [${KEYSTONE_IP}]"
+echo "Keystone Admin Token: [${KEYSTONE_ADMIN_TOKEN}]"
+
+cat << EOF > ./nova.rc
+export SERVICE_ENDPOINT=http://${KEYSTONE_IP}:35357/v2.0/
+export SERVICE_TOKEN=${KEYSTONE_ADMIN_TOKEN}
+export OS_AUTH_URL=http://${KEYSTONE_IP}:35357/v2.0/
+export OS_USERNAME=admin
+export OS_PASSWORD=openstack
+export OS_TENANT_NAME=admin
+EOF
+
+juju scp ./nova.rc nova-cloud-controller/0:~
+```  
+This script extract the required information and then copies the file to the instance running the nova-cloud-controller.
+Before we do any nova or glance command we will load the file we just created:
+
+```
+$ source ./nova.rc
+$ nova endpoints
+```
+
+At this point the output of nova endpoints should show the information of all the available OpenStack endpoints.
+
+### Install the Ubuntu Cloud Image
+
+In order for OpenStack to create instances in its cloud, it needs to have access to relevant images
+$ mkdir ~/iso
+$ cd ~/iso
+$ wget http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
+
+###Import the Ubuntu Cloud Image into Glance
+!!!Note:  glance comes with the package glance-client which may need to be installed where you plan the run the command from
+
+```
+apt-get install glance-client
+glance add name="Trusty x86_64" is_public=true container_format=ovf disk_format=qcow2 < trusty-server-cloudimg-amd64-disk1.img
+```
+###Create OpenStack private network
+Note:  nova-manage  can be run from the nova-cloud-controller node or any of the nova-compute nodes. To access the node we run the following command:
+
+```
+juju ssh nova-cloud-controller/0
+
+sudo nova-manage network create --label=private --fixed_range_v4=1.1.21.32/27 --num_networks=1 --network_size=32 --multi_host=T --bridge_interface=eth0 --bridge=br100
+```
+
+To make sure that we have created the network we can now run the following command:
+
+```
+sudo nova-manage network list
+```
+
+### Create OpenStack public network
+```
+sudo nova-manage floating create --ip_range=1.1.21.64/26
+sudo nova-manage floating list
+```
+Allow ping and ssh access adding them to the default security group
+Note: The following commands are run from a machine where we have the package python-novaclient installed and within a session where we have loaded the above created nova.rc file.
+
+```
+nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
+nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
+```
+
+###Create and register the ssh keys in OpenStack
+Generate a default keypair
+```
+ssh-keygen -t rsa -f ~/.ssh/admin-key
+```
+###Copy the public key into Nova
+We will name it admin-key:
+Note: In the precise version of python-novaclient the command works with --pub_key instead of --pub-key
+
+```
+nova keypair-add --pub-key ~/.ssh/admin-key.pub admin-key
+```
+And make sure it’s been successfully created:
+```
+nova keypair-list
+```
+
+###Create a test instance
+We created an image with glance before. Now we need the image ID to start our first instance. The ID can be found with this command:
+```
+nova image-list
+```
+
+Note: we can also use the command glance image-list
+###Boot the instance:
+
+```
+nova boot --flavor=m1.small --image=< image_id_from_glance_index > --key-name admin-key testserver1
+```
+
+###Add a floating IP to the new instance
+First we allocate a floating IP from the ones we created above:
+
+```
+nova floating-ip-create
+```
+
+Then we associate the floating IP obtained above to the new instance:
+
+```
+nova add-floating-ip 9363f677-2a80-447b-a606-a5bd4970b8e6  1.1.21.65
+```
+
+
+### Create and attach a Cinder volume to the instance
+Note: All these steps can be also done through the Horizon Web UI
+
+We make sure that cinder works by creating a 1GB volume and attaching it to the VM:
+
+```
+cinder create --display_name test-cinder1 1
+```
+
+Get the ID of the volume with cinder list:
+
+```
+cinder list
+```
+
+Attach it to the VM as vdb
+
+```
+nova volume-attach test-server1 bbb5c5c2-a5fd-4fe1-89c2-d16fe91578d4 /dev/vdb
+```
+
+Now we should be able to ssh the VM test-server1 from a server with the private key we created above and see that vdb appears in /proc/partitions
+
+
+
+
+[troubleshooting]
+[oog](http://docs.openstack.org/ops/)
+[MAAS tags]
+[openstack-config.yaml]
+[ceph](http://ceph.com/docs/master/dev/mon-bootstrap/)
 
=== added file 'Install/landcsape.md'
--- Install/landcsape.md	1970-01-01 00:00:00 +0000
+++ Install/landcsape.md	2014-04-15 16:06:33 +0000
@@ -0,0 +1,909 @@
+Title: Landscape
+#Managing OpenStack with Landscape
+
+##About Landscape
+Landscape is a system management tool designed to let you easily manage multiple Ubuntu systems - up to 40,000 with a single Landscape instance. From a single dashboard you can apply package updates and perform other administrative tasks on many machines. You can categorize machines by group, and manage each group separately. You can make changes to targeted machines even when they are offline; the changes will be applied next time they start. Landscape lets you create scripts to automate routine work such as starting and stopping services and performing backups. It lets you use both common Ubuntu repositories and any custom repositories you may create for your own computers. Landscape is particularly adept at security updates; it can highlight newly available packages that involve security fixes so they can be applied quickly. You can use Landscape as a hosted service as part of Ubuntu Advantage, or run it on premises via Landscape Dedicated Server.
+
+##Ubuntu Advantage
+Ubuntu Advantage comprises systems management tools, technical support, access to online resources and support engineers, training, and legal assurance to keep organizations on top of their Ubuntu server, desktop, and cloud deployments. Advantage provides subscriptions at various support levels to help organizations maintain the level of support they need.
+
+
+
+
+
+##Access groups
+
+
+
+
+Landscape lets administrators limit administrative rights on computers
+by assigning them to logical groupings called access groups. Each
+computer can be in only one access group, but you can organize access
+groups hierarchically to mirror the organization of your business. In
+addition to computers, access groups can contain package profiles,
+scripts, and custom graphs.
+
+Creating access groups
+----------------------
+
+A new Landscape installation comes with a single access group, called
+global, which gives any administrators who are associated with roles
+that include that access group control over every computer managed by
+Landscape. Most organizations will want to subdivide administration
+responsibilities by creating logical groupings of computers. You can
+create new access groups from the ACCESS GROUPS menu under your account
+menu.
+
+**Figure 5.1.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups1.png)
+
+\
+
+To create a new access group, you must provide two pieces of
+information: a title for the access group and a parent.
+
+To start with, the parent must be the global access group. If you want a
+flat management hierarchy, you can make every access group a child of
+global. Alternatively, you can use parent/child relationships to create
+a hierarchy of access groups. For instance, you could specify different
+sites at a high level, and under them individual buildings, and finally
+individual departments. Such a hierarchy allows you to specify groups of
+computers to be managed together by one administrator. Administrators
+whose roles are associated with higher-level access groups can manage
+all subgroups of which their access group is a parent.
+
+When a new access group is first created, its administrators are those
+who have roles linked to its parent access group, but you can edit the
+roles associated with an access group. To change the roles associated
+with an access group, see
+[below](https://landscape.canonical.com/static/doc/user-guide/ch05.html#associatingadmins "Associating roles with access groups").
+
+Adding computers to access groups
+---------------------------------
+
+To see all the computers currently in an access group, click on the name
+of the group in the ACCESS GROUPS screen. The screen that then appears
+displays information about that group. On the right side of the screen,
+click the word "computers" to show the list of computers that are
+currently members of this access group.
+
+**Figure 5.2.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups2.png)
+
+\
+Alternatively, you can click on the COMPUTERS menu item at the top of
+the Landscape screen, and in the selection box at the top of the left
+column, enter `access-group:`{.literal} followed by the name of your
+access group: for instance, `access-group:stagingservers`{.literal}.
+
+To add computers to an access group, click on the COMPUTERS menu item at
+the top of the Landscape screen. The resulting INFO screen shows the
+total number of available computers being managed by Landscape, and the
+number of computers currently selected:
+
+**Figure 5.3.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups3.png)
+
+\
+Find computers you wish to include (see the documentation on [selecting
+computers](https://landscape.canonical.com/static/doc/user-guide/ch06.html#selectingcomputers "Selecting computers")),
+then tick the checkbox next to each computer you wish to select. Once
+you've made your selection, click on the INFO menu entry at the top of
+the page Scroll down to the bottom section, choose the access group you
+want from the drop-down list, then click Update access group.
+
+**Figure 5.4.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups4.png)
+
+\
+
+Associating roles with access groups
+------------------------------------
+
+An administrator may manage an access group if he is associated with a
+role that has permission to do so. To associate a role with one or more
+access groups, click on the ROLES menu item under your account to
+display a screen that shows a role membership matrix.
+
+**Figure 5.5.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups5.png)
+
+\
+The top of that screen shows a list of role names. Click on a role name
+to edit the permissions and access groups associated with that role.
+Note that you cannot modify the GlobalAdmin role, so there is no link
+associated with that label at the top of the matrix.
+
+Editing access groups
+---------------------
+
+To change the name or title of an existing access group, click on the
+name of the group in the ACCESS GROUPS screen, then click on the Edit
+access group link at the top of next screen. Make changes, then click
+Save.
+
+**Figure 5.6.**
+
+![image](./Chapter%A05.%A0Access%20groups_files/accessgroups6.png)
+
+\
+
+Deleting access groups
+----------------------
+
+To delete an existing access group, click on the name of the group in
+the ACCESS GROUPS screen, then click on the Edit access group link at
+the top of next screen. On the resulting screen, click the Delete
+button. You may Confirm the group's deletion, or you can click Cancel to
+abort the operation. When you delete an access group, its resources move
+to its parent access group.
+
+**Figure 5.7.**
+
+
+
+##Managing computers
+
+
+Provisioning new computers
+--------------------------
+
+Landscape can provision computers in two ways: manually, or via metal as
+a service (MAAS). [The Ubuntu wiki explains how to set up
+MAAS](https://wiki.ubuntu.com/ServerTeam/MAAS/).
+
+To manually provision computers, click on PROVISIONING under your
+ACCOUNT menu. Landscape displays a provisioning dashboard that shows the
+number of provisioning servers you have set up, managed systems, and
+pending systems.
+
+**Figure 6.1.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers1.png)
+
+\
+
+To provision new systems, click the Provision new systems link. On the
+Provisioning New Systems screen, the top three fields apply to all the
+computers you wish to provision at one time.
+
+**Figure 6.2.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers2.png)
+
+\
+Enter the Ubuntu release/architecture from a drop-down list; the
+available choices are the two hardware architectures (i386 and amd64)
+for the each Ubuntu release beginning with 12.04. Enter the access group
+to which the new systems should belong from a drop-down list of the
+access groups set up for your account. You can optionally enter user
+data, which Landscape can use for special processing. For instance, you
+could use this field with Ubuntu's
+[cloud-init](https://help.ubuntu.com/community/CloudInit) utility, which
+handles early initialization functions for a cloud instance.
+
+For each computer you wish to provision, enter its MAC address,
+hostname, an optional title that will be displayed on the computer
+listing screen after the computer is set up, and optional tags separated
+by commas that can later help you search for this computer. Click the
+Add more systems link to get a new line of empty boxes into which you
+can add data.
+
+When you click the Next button, Landscape displays a screen that lets
+you review the information you entered.
+
+**Figure 6.3.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers3.png)
+
+\
+You can click on Back to make changes, or Provision to perform the
+operation. Landscape then displays a status screen that at first shows
+the specified computers waiting to boot on the MAAS server.
+
+**Figure 6.4.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers4.png)
+
+\
+
+Registering computers
+---------------------
+
+If a computer is provisioned by Landscape, is it automatically
+registered with Landscape, but when you first install Landscape, your
+computers are not known to the Landscape server. To manage them, you
+must register them with the server. Complete instructions for
+registering client computers with a Landscape server are available at
+https://yourserver/standalone/how-to-register. You can get to this page
+by first clicking on the menu item for your account page on the top
+menu, then on the link in the box on the left side of the page.
+
+Selecting computers
+-------------------
+
+You can select one or more computers individually, or by using searches
+or tags. For each of those approaches, the starting place is the
+COMPUTERS menu entry at the top of the screen. Clicking on it displays a
+list of all computers Landscape knows about.
+
+-   To select computers individually, tick the boxes beside their names
+    in the Select computers list.
+
+-   Using searches - The upper left corner of the Select computers
+    screen displays the instructions "Refine your selection by searching
+    or selecting from the tags below," followed by a search box. You can
+    enter any string in that box and press Enter, or click the arrow
+    next to the box. Landscape will search both the name and hostname
+    associated with all computers for a match with the search term.
+    Searches are not case-sensitive. A list of matching computers is
+    displayed on the right side of the screen.
+
+    Once you've selected a group of computers, you can apply a tag to
+    them to make it easier to find them again. To do so, with your
+    computers selected, click on INFO under COMPUTERS. In the box under
+    Tags:, enter the tag you want to use and click Add.
+
+-   Using tags - Any tags you have already created appear in a list
+    under the search box on the left of the Computers screens. You can
+    click on any tag to display the list of computers associated with
+    it. To select any of the displayed computers, tick the box next to
+    its name, or click Select: All link at the top of the list.
+
+Information about computers
+---------------------------
+
+By clicking on several submenus of the COMPUTERS menu, you can get
+information about selected computers.
+
+-   Clicking on ACTIVITIES displays information about actions that may
+    be applied to computers. You can filter the activity log to show
+    All, Pending, Unapproved, or Failed activities. You can click on
+    each activity in the list to display a screen showing details about
+    the activity. On that screen you can Approve, Cancel, Undo, or Redo
+    the activity by clicking on the relevant button.
+
+-   Clicking on HARDWARE displays information about the selected
+    computer's processor, memory, network, storage, audio, video, PCI,
+    and USB hardware, as well as BIOS information and CPU flags.
+
+    **Figure 6.5.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers5.png)
+
+    \
+
+-   Clicking on PROCESSES displays information about all processes
+    running on a computer at the last time it checked in with the
+    Landscape server, and lets you end or kill processes by selecting
+    them and clicking on the relevant buttons.
+
+    **Figure 6.6.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers6.png)
+
+    \
+
+-   Clicking on REPORTS displays seven pie charts that show what
+    percentage of computers:
+
+    -   are securely patched
+
+    -   are covered by upgrade profiles
+
+    -   have contacted the server within the last five minutes
+
+    -   have applied security updates - four charts show computers that
+        have applied Ubuntu Security Notices within the last two, 14,
+        30, and 60+ days
+
+-   Clicking on MONITORING displays graphs of key performance
+    statistics, such as CPU load, memory use, disk use, and network
+    traffic.
+
+    **Figure 6.7.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers7.png)
+
+    \
+    You can also create custom graphs to display at the top of the page
+    by clicking on the Create some now! link. A drop-down box at the top
+    of the page lets you specify the timeframe the graph data covers:
+    one day, three days, one week, or four weeks. You can download the
+    data behind each graph by clicking the relevant button under the
+    graph.
+
+The activity log
+----------------
+
+The right side of the dashboard that displays when you click on your
+account menu, and when you click on the ACTIVITIES submenu, shows the
+status of Landscape activities, displayed in reverse chronological
+order.
+
+**Figure 6.8.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers8.png)
+
+\
+You can view details on an individual activity by clicking on its
+description. Each activity is labeled with a status; possible values
+are:
+
+-   Succeeded
+
+-   In progress
+
+-   Scheduled
+
+-   Queued
+
+-   Unapproved
+
+-   Canceled
+
+-   Failed
+
+You can select a subset to view by clicking on the links above the table
+for All, Pending, Unapproved, or Failed activities.
+
+In addition to the status and description of each activity, the table
+shows what computers the activity applied to, who created it, and when.
+
+Managing users
+--------------
+
+Clicking on USERS displays a list of users on each of the selected
+computers.
+
+**Figure 6.9.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers9.png)
+
+\
+You can select one or more users, then click one of the buttons at the
+top of the screen:
+
+-   The ADD button lets you add a new user to the selected computers.
+
+    **Figure 6.10.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers10.png)
+
+    \
+    You must specify the person's name, a username, and a passphrase.
+    You may also specify a location and telephone numbers. Click the ADD
+    button at the bottom of the screen to complete the operation.
+
+-   The DELETE button displays a screen that lets you delete the
+    selected users.
+
+    **Figure 6.11.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers11.png)
+
+    \
+    You may also tick a checkbox to delete the user's home folders as
+    well. Press the Delete button at the bottom of the screen to
+    complete the operation.
+
+-   The EDIT button displays a User details screen that lets you change
+    details such as the person's name, primary group, passphrase,
+    location, and telephone numbers, and add or remove the user from
+    groups on the selected computers.
+
+    **Figure 6.12.**
+
+    ![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers12.png)
+
+    \
+
+-   The LOCK button prevents the selected users from logging into their
+    accounts.
+
+-   The UNLOCK button lets users into their cars when they've
+    accidentally locked their keys inside. Actually, no, it simply
+    unlocks previously locked accounts.
+
+Managing alerts
+---------------
+
+Landscape uses alerts to notify administrators of conditions that
+require attention. The following types of alerts are available:
+
+-   when a pending computer needs to be accepted or rejected
+
+-   when you are exceeding your license entitlements for Landscape
+    Dedicated Server (This alert does not apply to the hosted version of
+    Landscape.)
+
+-   when new package updates are available for computers
+
+-   when new security updates are available for computers
+
+-   when a package profile is not applied
+
+-   when package reporting fails (Each client runs the command **apt-get
+    update** every 60 minutes. Anything that prevents that command from
+    succeeding is considered a package reporting failure.)
+
+-   when an activity requires explicit administrator acceptance or
+    rejection
+
+-   when a computer has not contacted the Landscape server for more than
+    five minutes
+
+-   when computers need to be rebooted in order for a package update
+    (such as a kernel update) to take effect
+
+To configure alerts, click on the Configure alerts link in the
+dashboard, or click on your account's ALERTS menu item. Tick the check
+box next to each type of alert you want to subscribe to, or click the
+All or None buttons at the top of the table, then click on the Subscribe
+or Unsubscribe button below the table.
+
+**Figure 6.13.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers13.png)
+
+\
+
+The Alerts screen shows the status of each alert. If an alert has not
+been tripped, the status is OK; if it has, the status is Alerted. The
+last column notes whether the alert applies to your account (pending
+computers, for instance, are not yet Landscape clients, but they are
+part of your account), to all computers, or to a specified set of tagged
+computers.
+
+If an alert is tripped, chances are an administrator should investigate
+it. You can see alerts on the account dashboard that displays when you
+click on your account name on the top menu. The description for each
+alert is a link; click on it to see a table of alerts. When you click on
+an alert, the resulting screen shows relevant information about the
+problem. For instance, if you click on an alert about computers having
+issues reporting packages, the table shows the computer affected, the
+error code, and error output text.
+
+**Figure 6.14.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers14.png)
+
+\
+On some alert screens you can download the list of affected computers as
+a CSV file or save the criteria that generated the alert as a saved
+search by clicking the relevant button at the bottom of the screen.
+
+Managing scripts
+----------------
+
+Landscape lets you run scripts on the computers you manage in your
+account. The scripts may be in any language, as long as an interpreter
+for that language is present on the computers on which they are to run.
+You can maintain a library of scripts for common tasks. You can manage
+scripts from the STORED SCRIPTS menu under your account, and run them
+against computers from the SCRIPTS menu under COMPUTERS.
+
+The Stored scripts screen displays a list of existing scripts, along
+with the access groups each belongs to and its creator.
+
+**Figure 6.15.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers15.png)
+
+\
+You can edit a script by clicking on its name. To delete a stored
+script, tick the check box next to its name, then click Remove. If you
+have the proper permissions, Landscape erases the script immediately
+without asking for confirmation.
+
+From the Stored scripts screen you can add a new script by clicking on
+Add stored script.
+
+**Figure 6.16.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers16.png)
+
+\
+On the Create script screen you must enter a title, interpreter, the
+script code, the time within which the script must complete, and the
+access group to which the script belongs. You may enter a default user
+to run the script as; if you don't, you will have to specify the user
+when you choose to run the script. You may also attach as many as five
+files with a maximum of 1MB in total size. On each computer on which a
+script runs, attachments are placed in the directory specified by the
+environment variable LANDSCAPE\_ATTACHMENTS, and are deleted once the
+script has been run. After specifying all the information for a stored
+script, click on Save to save it.
+
+To run a stored script, go to the SCRIPTS menu under COMPUTERS. Here you
+can choose to run a stored script, or run a new script.
+
+**Figure 6.17.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers17.png)
+
+\
+When you choose to run an existing script, Landscape displays the script
+details, which allows you to modify any information. You must specify
+the user on the target computers to run the script as, and schedule the
+script to run either as soon as possible, or at a specified time. When
+you're ready to run the script, click on Run.
+
+To run a new script, you must enter most of the same information you
+would if you were creating a stored script, with three differences.
+
+**Figure 6.18.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers18.png)
+
+\
+On this screen you must specify the user on the target computers to run
+the script as, and you may optionally tick a check box to store the
+script in your script library. You must also schedule the script to run
+either as soon as possible, or at a specified time. When you're ready to
+run the script, click on Run.
+
+Managing upgrade profiles
+-------------------------
+
+An upgrade profile defines a schedule for the times when upgrades are to
+be automatically installed on the machines associated with a specific
+access group. You can associate zero or more computers with each upgrade
+profile via tags to install packages on those computers. You can also
+associate an upgrade profile with an access group, which limits its use
+to only computers within the specified access group. You can manage
+upgrade profiles from the UPGRADE PROFILES link in the PROFILES choice
+under your account.
+
+When you do so, Landscape displays a list of the names and descriptions
+of existing upgrade profiles.
+
+**Figure 6.19.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers19.png)
+
+\
+To see the details of an existing profile, click on its name to display
+a screen that shows the name, schedule, and tags of computers associated
+with the upgrade profile. If you want to change the upgrade profile's
+name or schedule, click on the Edit upgrade profile link. If you want to
+change the computers associated with the upgrade profile, tick or untick
+the check boxes next to the tags on the lower part of the screen, then
+click on the Change button. Though you can see the access group
+associated with the upgrade profile, you cannot change the access groups
+anywhere but from their association with a computer.
+
+To add an upgrade profile, click on the Add upgrade profile link.
+
+**Figure 6.20.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers20.png)
+
+\
+On the resulting Create an upgrade profile screen you must enter a name
+for the upgrade profile. Names can contain only letters, numbers, and
+hyphens. You may check a box to make the upgrade profile apply only to
+security upgrades; if you leave it unchecked, it will target all
+upgrades. Specify the access group to which the upgrade profile belongs
+from a drop-down list. Finally, specify the schedule on which the
+upgrade profile can run. You can specify a number of hours to let the
+upgrade profile run; if it does not complete successfully in that time,
+Landscape will trigger an alert. Click on the Save button to save the
+new upgrade profile.
+
+To delete one or more upgrade profiles, tick a check box next to the
+upgrade profiles' names, then click on the Remove button.
+
+Managing removal profiles
+-------------------------
+
+A removal profile defines a maximum number of days that a computer can
+go without exchanging data with the Landscape server before it is
+automatically removed. If more days pass than the profile's "Days
+without exchange", that computer will automatically be removed and the
+license seat it held will be released. This helps Landscape keep license
+seats open and ensure Landscape is not tracking stale or retired
+computer data for long periods of time. You can associate zero or more
+computers with each removal profile via tags to ensure those computers
+are governed by this removal profile. You can also associate a removal
+profile with an access group, which limits its use to only computers
+within the specified access group. You can manage removal profiles from
+the REMOVAL PROFILES link in the PROFILES choice under your account.
+
+When you do so, Landscape displays a list of the names and descriptions
+of existing removal profiles.
+
+**Figure 6.21.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers21.png)
+
+\
+To see the details of an existing profile, click on its name to display
+a screen that shows the title, name and number of days without exchange
+before the computer is automatically removed, and tags of computers
+associated with the removal profile. If you want to change the removal
+profile's title or number of days before removal, click on the Edit
+removal profile link. If you want to change the computers associated
+with the removal profile, tick or untick the check boxes next to the
+tags on the lower part of the screen, then click on the Change button.
+Though you can see the access group associated with the removal profile,
+you cannot change the access groups anywhere but from their association
+with a computer.
+
+To add a removal profile, click on the Add removal profile link.
+
+**Figure 6.22.**
+
+![image](./Chapter%A06.%A0Managing%20computers_files/managecomputers22.png)
+
+\
+On the resulting Create a removal profile screen you must enter a title
+for the removal profile. Specify the access group to which the removal
+profile belongs from a drop-down list. Finally, specify the number of
+days without exchange that computers will be allowed without contact
+before they are automatically removed and their license seat is
+released. If a computer does not contact Landscape within that number of
+days, it will subsequently be removed. Click on the Save button to save
+the new removal profile.
+
+To delete one or more removal profiles, tick a check box next to the
+removal profiles' names, then click on the Remove button.
+
+##Managing packages
+
+
+A package is a group of related files that comprise everything you need
+to install an application. Packages are stored in repositories, and each
+package is managed via a package profile, which is a record of the
+package's dependencies and conflicts.
+
+Package information
+-------------------
+
+Clicking on PACKAGES under the COMPUTERS menu displays a screen where
+you can search for information about all the packages Landscape knows
+about. You may first specify a package name or other search string, then
+press Enter or click on the arrow next to the box. Landscape then
+displays a list of packages that meet the search criteria.
+
+**Figure 7.1.**
+
+![image](./Chapter%A07.%A0Managing%20packages_files/managepackages1.png)
+
+\
+The top of the screen displays summary information about the packages:
+clickable links to which computers have security updates and other
+upgrades to be installed, and the number of computers that are
+up-to-date and those that have not reported package information.
+
+The next section provides a list of security issues on computers that
+need security updates. You can click on the name or USN number of a
+security issue to see a full Ubuntu Security Notice.
+
+**Figure 7.2.**
+
+![image](./Chapter%A07.%A0Managing%20packages_files/managepackages2.png)
+
+\
+The third section displays package information in the form of four
+numbers for each selected computer: the number of packages available and
+installed, pending upgrades, and held upgrades. You can click on the
+number of pending or held upgrades to see a screen that lets you modify
+the relevant package list and set a time for the upgrades to take place:
+
+**Figure 7.3.**
+
+![image](./Chapter%A07.%A0Managing%20packages_files/managepackages3.png)
+
+
+Finally, a Request upgrades button at the bottom of the screen lets you
+quickly request that all possible upgrades be applied to the selected
+computers. Any resulting activities require explicit administrator
+approval.
+
+Adding a package profile
+------------------------
+
+Landscape uses package profiles (also called meta packages) to make sure
+the proper software is installed when you request packages. You can
+think of a package profile as a package with no file contents, just
+dependencies and conflicts. With that information, the package profile
+can trigger the installation of other packages necessary for the
+requested package to run, or trigger the removal of software that
+conflicts with the requested package. These dependencies and conflicts
+fall under the general category of constraints.
+
+To manage package profiles, click the PROFILES menu entry under your
+account and the Package profiles link. The Package profiles screen
+displays a list of existing package profiles and a link that you can
+click to add a new package profile.
+
+**Figure 7.4.**
+
+![image](./Chapter%A07.%A0Managing%20packages_files/managepackages4.png)
+
+\
+Click on that link to display the Create package profile screen:
+
+**Figure 7.5.**
+
+![image](./Chapter%A07.%A0Managing%20packages_files/managepackages5.png)
+
+\
+Here you enter a name for the package profile, a description (which
+appears at the top of the package profile's information screen), the
+access group to which the package profile should belong, and,
+optionally, any package constraints - packages that this profile depends
+on or conflicts with. The constraints drop-down lists lets you add
+constraints in three ways: based on a computer's installed packages,
+imported from a previously exported CSV file or the output of the **dpkg
+--get-selections** command, or manually added. Use the first option if
+you want to replicate one computer to another, as it makes all currently
+installed packages that are on the selected computer dependencies of the
+package profile you're creating. The second approach imports the
+dependencies of a previously exported package profile. The manual
+approach is suitable when you have few dependencies to add, all of which
+you know.
+
+When you save a package profile, behind the scenes Landscape creates a
+Debian package with the specified dependencies and conflicts and gives
+it a name and a version. Every time you change the package profile,
+Landscape increments the version by one.
+
+If Landscape finds computers on which the package profile should be
+installed, it creates an activity to do so. That activity will run
+unattended, except that you must provide explicit administrator approval
+to remove any packages that the package profile wants to delete.
+
+Exporting a package profile
+---------------------------
+
+You can export a package profile in order to use the same constraints
+it's set up for with a new package profile. To export a package profile,
+click the PROFILES menu entry under your account and the Package
+profiles link. Tick the check box next to the packages you want to
+export, then click Download as CSV.
+
+Modifying a package profile
+---------------------------
+
+To modify a package profile, click the PROFILES menu entry under your
+account and the Package profiles link, then click on the name of a
+package profile in the list.
+
+Deleting a package profile
+--------------------------
+
+To delete a package profile, click the PROFILES menu entry under your
+account and then the Package profiles link. Tick the check box next to
+the packages you want to delete, then click Remove. The package profile
+is deleted immediately, with no prompt to confirm the action.
+
+Repositories
+------------
+
+Packages are stored in repositories. A repository is simply a designated
+location that stores packages. You can manage Landscape repositories
+only via [the Landscape
+API](https://landscape.canonical.com/static/doc/user-guide/ch09.html "Chapter 9. The Landscape API").
+
+
+
+
+* * * * *
+
+[Prev](https://landscape.canonical.com/static/doc/user-guide/ch07.html)
+[Up](https://landscape.canonical.com/static/doc/user-guide/index.html)
+[Next](https://landscape.canonical.com/static/doc/user-guide/ch09.html)
+
+##Use cases
+--------------------
+
+
+You can use Landscape to perform many common system administration tasks
+easily and automatically. Here are a few examples.
+
+How do I upgrade all packages on a certain group of machines?
+-------------------------------------------------------------
+
+First, tag the machines you want to upgrade with a common tag, so you
+can use the tag anytime you need to manage those computers as a group.
+If, for instance, you want to upgrade all your desktop computers, you
+might want to use "desktop" as a tag. Select your computers, then click
+on COMPUTERS on the top menu, and under that INFO. In the box under
+Tags:, enter the tag you want to use and click the Add button.
+
+If you've already tagged the computers, click on COMPUTERS, then click
+on the tag in the left column.
+
+With your desktop computers selected, click on COMPUTERS, then PACKAGES.
+Scroll to the bottom of the screen, where you'll see a Request upgrades
+button. Click it to queue the upgrade tasks.
+
+![image](./Chapter%A08.%A0Use%20cases_files/usecases1.png)
+
+While the upgrade tasks are now in the queue, they will not be executed
+until you approve them. To do so, next to Select:, click All, then click
+on the Approve button at the bottom of the page.
+
+How do I keep all of my file servers automatically up to date?
+--------------------------------------------------------------
+
+The best way is to use [upgrade
+profiles](https://landscape.canonical.com/static/doc/user-guide/ch02.html#defineupgradeprofiles),
+which rely on access groups.
+
+If an access group for your file servers already exists, simply click on
+its name. If not, you must create an access group for them. To do so,
+click on your account, then on ACCESS GROUPS. Specify a name for your
+new access group and click the Save button. You must then add computers
+to the access group. To do that, click on COMPUTERS, then select all
+your file servers by using a tag, if one exists, or a search, or by
+ticking them individually. Once all the computers you want to add to the
+access group are tagged, click on the INFO menu choice, scroll down to
+the bottom section, choose the access group you want from the drop-down
+list, then click the Update access group button.
+
+![image](./Chapter%A08.%A0Use%20cases_files/accessgroups4.png)
+
+Once you have all your file servers in an access group you can create an
+upgrade profile for them. Click on your account, then PROFILES menu
+following the Upgrade profiles link, and then on the Add upgrade profile
+link. Enter a name for the new upgrade profile, choose the access group
+you wish to associate with it, and specify the schedule on which the
+upgrades should run, then click the Save button.
+
+How do I keep Landscape from upgrading a certain package on one of my servers?
+------------------------------------------------------------------------------
+
+First find the package by clicking on COMPUTERS, then PACKAGES. Use the
+search box at the top of the screen to find the package you want. Click
+the triangle on the left of the listing line of the package you want to
+hold, which expands the information for that package. Now click on the
+icon to the left of the package name. A new icon with a lock replaces
+the old one, indicating that this package is to be held during upgrades.
+Scroll to the bottom of the page and click on the Apply Changes button.
+
+![image](./Chapter%A08.%A0Use%20cases_files/usecases2.png)
+
+How do I set up a custom graph?
+-------------------------------
+
+First select the computers whose information you want to see. One good
+way to do so is to create a tag for that group of computers on my
+computers. Suppose you want to monitor the size of the PostgreSQL
+database on your database servers. Select the servers, then click on
+COMPUTERS on the top menu, and INFO under that. In the box under Tags:,
+enter a tag name, such as "db-server," and click the Add button. Next,
+under your account, click on CUSTOM GRAPHS, then on the link to Add
+custom graph. Enter a title, and in the \#! field, enter **/bin/sh** to
+indicate a shell script. In the Code section, enter the commands
+necessary to create the data for the graph. For this example, the
+command might be:
+
+~~~~ {.programlisting}
+psql -tAc "select pg_database_size('postgres')"
+~~~~
+
+For Run as user, enter **postgres**.
+
+Fill in the Y-axix title, then click the Save button at the bottom of
+the page.
+
+![image](./Chapter%A08.%A0Use%20cases_files/usecases3.png)
+
+To view the graph, click on COMPUTERS, then MONITORING. You can select
+the monitoring period from the drop-down box at the top of the window.
+
+How do I ensure all computers with a given tag have a common list of packages installed?
+----------------------------------------------------------------------------------------
+
+Manage them via a [package
+profile](https://landscape.canonical.com/static/doc/user-guide/ch07.html#definepp "Adding a package profile").
+
+
 
=== removed file 'Installing-Ceph.md'
--- Installing-Ceph.md	2014-04-07 13:23:30 +0000
+++ Installing-Ceph.md	1970-01-01 00:00:00 +0000
@@ -1,56 +0,0 @@
-Title: Installing - Ceph
-Status: Review
-
-# Installing - Ceph
-
-## Introduction
-
-Typically OpenStack uses the local storage of their nodes for the configuration data
-as well as for the object storage provided by Swift and the block storage provided by 
-Cinder and Glance. But it also can use Ceph as storage backend. Ceph stripes block 
-device images across a cluster. This way it provides a better performance than typical 
-standalone server. It allows scalabillity and redundancy needs to be satisfied and 
-Cinder's RDB driver used to create, export and connect volumes to instances.
-
-## Scope
-
-This document covers the deployment of Ceph via Juju. Other related documents are
-
-- [Scaling Ceph](Scaling-Ceph.md)
-- [Troubleshooting Ceph](Troubleshooting-Ceph.md)
-- [Appendix Ceph and OpenStack](Appendix-Ceph-and-OpenStack.md)
-
-## Deployment
-
-During the installation of OpenStack we've already seen the deployment of Ceph via
-
-```
-juju deploy --config openstack-config.yaml -n 3 ceph
-juju deploy --config openstack-config.yaml -n 10 ceph-osd
-```
-
-This will install three Ceph nodes configured with the information contained in the
-file `openstack-config.yaml`. This file contains the configuration `block-device: None`
-for Cinder, so that this component does not use the local disk. Instead we're calling
-Additionally 10 Ceph OSD nodes providing the object storage are deployed and related 
-to the Ceph nodes by
-
-```
-juju add-relation ceph-osd ceph
-```
-
-Once the ceph charm has bootstrapped the cluster, it will notify the ceph-osd charm which 
-will scan for the configured storage devices and add them to the pool of available storage.
-Now the relation to Cinder and Glance can be established with
-
-```
-juju add-relation cinder ceph
-juju add-relation glance ceph
-```
-
-so that both are using the storage provided by Ceph.
-
-## See also
-
-- https://manage.jujucharms.com/charms/precise/ceph
-- https://manage.jujucharms.com/charms/precise/ceph-osd
 
=== removed file 'Installing-MAAS.md'
--- Installing-MAAS.md	2014-04-02 23:18:00 +0000
+++ Installing-MAAS.md	1970-01-01 00:00:00 +0000
@@ -1,467 +0,0 @@
-Title: Installing MAAS 
-Status: In progress
-Notes:
-
-
-
-
-
-#Installing the MAAS software
-
-##Scope of this documentation
-
-This document provides instructions on how to install the Metal As A Service (MAAS) software. It has been prepared alongside guides for installing Juju, OpenStack and Landscape as part of a production grade cloud environment. MAAS itself may be used in different ways and you can find documentation for this on the main MAAS website [MAAS docs]. For the purposes of this documentation, the following assumptions have been made:
-* You have sufficient, appropriate node hardware 
-* You will be using Juju to assign workloads to MAAS
-* You will be configuring the cluster network to be controlled entirely by MAAS (i.e. DNS and DHCP)
-* If you have a compatible power-management system, any additional hardware required is also installed(e.g. IPMI network).
-
-## Introducing MAAS
-
-Metal as a Service – MAAS – lets you treat physical servers like virtual machines in the cloud. Rather than having to manage each server individually, MAAS turns your bare metal into an elastic cloud-like resource.
-
-What does that mean in practice? Tell MAAS about the machines you want it to manage and it will boot them, check the hardware’s okay, and have them waiting for when you need them. You can then pull nodes up, tear them down and redeploy them at will; just as you can with virtual machines in the cloud.
-
-When you’re ready to deploy a service, MAAS gives Juju the nodes it needs to power that service. It’s as simple as that: no need to manually provision, check and, afterwards, clean-up. As your needs change, you can easily scale services up or down. Need more power for your Hadoop cluster for a few hours? Simply tear down one of your Nova compute nodes and redeploy it to Hadoop. When you’re done, it’s just as easy to give the node back to Nova.
-
-MAAS is ideal where you want the flexibility of the cloud, and the hassle-free power of Juju charms, but you need to deploy to bare metal.
-
-## Installing MAAS from the Cloud Archive
-
-The Ubuntu Cloud Archive is a repository made especially to provide users with the most up to date, stable versions of MAAS, Juju and other tools. It is highly recommended to configure this repository and use it to keep your software up to date:
-
-```
-sudo add-apt-repository cloud-archive:tools
-sudo apt-get update
-```
-
-There are several packages that comprise a MAAS install. These are:
-
-maas-region-controller:
-    Which comprises the 'control' part of the software, including the web-based user interface, the API server and the main database.
-maas-cluster-controller:
-    This includes the software required to manage a cluster of nodes, including managing DHCP and boot images.
-maas-dns:
-    This is a customised DNS service that MAAS can use locally to manage DNS for all the connected nodes.
-mass-dhcp:
-    As for DNS, there is a DHCP service to enable MAAS to correctly enlist nodes and assign IP addresses. The DHCP setup is critical for the correct PXE booting of nodes.
-
-As a convenience, there is also a `maas` metapackage, which will install all these components
-
-
-If you need to separate these services or want to deploy an additional cluster controller, you should install the corresponding packages individually (see [_the description of a typical setup_](https://www.filepicker.io/api/file/orientation.html#setup) for more background on how a typical hardware setup might be arranged).
-
-
-
-
-### Installing the packages
-
-The configuration for the MAAS controller will automatically run and pop up this config screen:
-
-![]( install_cluster-config.png)
-
-Here you will need to enter the hostname for where the region controller can be contacted. In many scenarios, you may be running the region controller (i.e. the web and API interface) from a different network address, for example where a server has several network interfaces.
-
-Once the configuration scripts have run you should see this message telling you that the system is ready to use:
-
-![]( install_controller-config.png)
-
-The web server is started last, so you have to accept this message before the service is run and you can access the Web interface. Then there are just a few more setup steps [_Post-Install tasks_](https://www.filepicker.io/api/file/WMGTttJT6aaLnQrEkAPv?signature=a86d0c3b4e25dba2d34633bbdc6873d9d8e6ae3cecc4672f2219fa81ee478502&policy=eyJoYW5kbGUiOiJXTUdUdHRKVDZhYUxuUXJFa0FQdiIsImV4cGlyeSI6MTM5NTE3NDE2MSwiY2FsbCI6WyJyZWFkIl19#post-install)
-
-The maas-dhcp and maas-dns packages should be installed by default. You can check whether they are installed with:
-
-```
-dpkg -l maas-dhcp maas-dns
-```
-
-If they are missing, then:
-
-```
-sudo apt-get install maas-dhcp maas-dns
-```
-
-And then proceed to the post-install setup below.
-
-If you now use a web browser to connect to the region controller, you should see that MAAS is running, but there will also be some errors on the screen:
-
-![]( install_web-init.png)
-
-The on screen messages will tell you that there are no boot images present, and that you can't login because there is no admin user.
-
-## Create a superuser account
-
-Once MAAS is installed, you'll need to create an administrator account:
-
-```
-sudo maas createadmin --username=root --email=[e-mail]
-```
-
-Substitute your own email address in the command above. You may also use a different username for your administrator account, but "root" is a common convention and easy to remember. The command will prompt for a password to assign to the new user.
-
-You can run this command again for any further administrator accounts you may wish to create, but you need at least one.
-
-## Import the boot images
-
-MAAS will check for and download new Ubuntu images once a week. However, you'll need to download them manually the first time. To do this you will need to connect to the MAAS API using the maas-cli tool. (see for details). Then you need to run the command:
-
-```
-maas-cli maas node-groups import-boot-images
-```
-
-(substitute in a different profile name for 'maas' if you have called yours something else) This will initiate downloading the required image files. Note that this may take some time depending on your network connection.
-
-
-## Login to the server
-
-To check that everything is working properly, you should try and login to the server now. Both the error messages should have gone (it can take a few minutes for the boot image files to register) and you can see that there are currently 0 nodes attached to this controller.
-
-![]( install-login.png)
-## Configure switches on the network
-
-Some switches use Spanning-Tree Protocol (STP) to negotiate a loop-free path through a root bridge. While scanning, it can make each port wait up to 50 seconds before data is allowed to be sent on the port. This delay in turn can cause problems with some applications/protocols such as PXE, DHCP and DNS, of which MAAS makes extensive use.
-
-To alleviate this problem, you should enable [Portfast](https://www.symantec.com/business/support/index?page=content&id=HOWTO6019) for Cisco switches or its equivalent on other vendor equipment, which enables the ports to come up almost immediately.
-
-##Add an additional cluster
-
-Whilst it is certainly possible to run MAAS with just one cluster controller for all the nodes, in the interests of easier maintenance, uprades and stability, it is desirable to have at least two operational clusters.
-
-Each cluster needs a controller node. Install Ubuntu on this node and then follow a similar setup proceedure to install the cluster controller software:
-
-```
-sudo add-apt-repository cloud-archive:tools
-sudo apt-get update
-sudo apt-get install maas-cluster-controller
-sudo apt-get install maas-dhcp
-```
-
-During the install process, a configuration window will appear. You merely need to type in the address of the MAAS controller API, like this:
-
-![config-image.png]
-
-## Configure Cluster Controller(s)
-
-### Cluster acceptance
-When you install your first cluster controller on the same system as the region controller, it will be automatically accepted by default (but not yet configured, see below). Any other cluster controllers you set up will show up in the user interface as “pending,” until you manually accept them into the MAAS.
-
-To accept a cluster controller, click on the settings “cog” icon at the top right to visit the settings page:
-![]settings.png
-You can either click on “Accept all” or click on the edit icon to edit the cluster. After clicking on the edit icon, you will see this page:
-
-![]cluster-edit.png
-Here you can change the cluster’s name as it appears in the UI, its DNS zone, and its status. Accepting the cluster changes its status from “pending” to “accepted.”
-
-Now that the cluster controller is accepted, you can configure one or more of its network interfaces to be managed by MAAS. This will enable the cluster controller to manage nodes attached to those networks. The next section explains how to do this and what choices are to be made.
-
-### Configuration
-MAAS automatically recognises the network interfaces on each cluster controller. Some of these will be connected to networks where you want to manage nodes. We recommend letting your cluster controller act as a DHCP server for these networks, by configuring those interfaces in the MAAS user interface.
-
-As an example, we will configure the cluster controller to manage a network on interface eth0. Click on the edit icon for eth0, which takes us to this page:
-
-![]cluster-interface-edit.png
-Here you can select to what extent you want the cluster controller to manage the network:
-
-DHCP only - this will run a DHCP server on your cluster
-DHCP and DNS - this will run a DHCP server on the cluster and configure the DNS server included with the region controller so that it can be used to look up hosts on this network by name.
-Note
-You cannot have DNS management without DHCP management because MAAS relies on its own DHCP server’s leases file to work out the IP address of nodes in the cluster.
-If you set the interface to be managed, you now need to provide all of the usual DHCP details in the input fields below. Once done, click “Save interface”. The cluster controller will now be able to boot nodes on this network.
-
-!!! note:There is also an option to leave the network unmanaged. Use this for networks where you don’t want to manage any nodes. Or, if you do want to manage nodes but don’t want the cluster controller to serve DHCP, you may be able to get by without it. This is explained in Manual DHCP configuration.
-
-!!! note: A single cluster controller can manage more than one network, each from a different network interface on the cluster-controller server. This may help you scale your cluster to larger numbers of nodes, or it may be a requirement of your network architecture.
-
-## Enlisting nodes
-
-Now that the MAAS controller is running, we need to make the nodes aware of MAAS and vice-versa. With MAAS controlling DHCP and nodes capable of PXE booting, this is straightforward
-
-Automatic Discovery
-With nodes set to boot from a PXE image, they will start, look for a DHCP server, receive the PXE boot details, boot the image, contact the MAAS server and shut down.
-
-During this process, the MAAS server will be passed information about the node, including the architecture, MAC address and other details which will be stored in the database of nodes. You can accept and comission the nodes via the web interface. When the nodes have been accepted the selected series of Ubuntu will be installed.
-
-To save time, you can also accept and commission all nodes from the commandline. This requires that you first login with the API key [1], which you can retrieve from the web interface:
-
-```
-maas-cli maas nodes accept-all
-```
-
-### Manually adding nodes
-
-If your nodes are not capable of booting from PXE images, they can be manually registered with MAAS. On the Nodes screen:
-![]add-node.png
-
-Select 'Add node' and manually enter details about the node, including its MAC address. This is used to identify the node when it contacts the DHCP server.
-
-
-
-## Preparing MAAS for Juju using Simplestreams
-
-When Juju bootstraps a cloud, it needs two critical pieces of information:
-
-1. The uuid of the image to use when starting new compute instances.
-2. The URL from which to download the correct version of a tools tarball.
-
-This necessary information is stored in a json metadata format called "simplestreams". For supported public cloud services such as Amazon Web Services, HP Cloud, Azure, etc, no action is required by the end user. However, those setting up a private cloud, or who want to change how things work (eg use a different Ubuntu image), can create their own metadata, after understanding a bit about how it works.
-
-The simplestreams format is used to describe related items in a structural fashion.( [See the Launchpad project lp:simplestreams for more details on implementation](https://launchpad.net/simplestreams)). Below we will discuss how Juju determines which metadata to use, and how to create your own images and tools and have Juju use them instead of the defaults.
-
-### Basic Workflow
-
-Whether images or tools, Juju uses a search path to try and find suitable metadata. The path components (in order of lookup) are:
-
-1. User supplied location (specified by tools-metadata-url or image-metadata-url config settings).
-2. The environment's cloud storage.
-3. Provider specific locations (eg keystone endpoint if on Openstack).
-4. A web location with metadata for supported public clouds (https://streams.canonical.com).
-
-Metadata may be inline signed, or unsigned. We indicate a metadata file is signed by using the '.sjson' extension. Each location in the path is first searched for signed metadata, and if none is found, unsigned metadata is attempted before moving onto the next path location.
-
-Juju ships with public keys used to validate the integrity of image and tools metadata obtained from https://streams.canonical.com. So out of the box, Juju will "Just Work" with any supported public cloud, using signed metadata. Setting up metadata for a private (eg Openstack) cloud requires metadata to be generated using tools which ship with Juju.
-
-### Image Metadata Contents
-
-Image metadata uses a simplestreams content type of "image-ids". The product id is formed as follows:
-
-com.ubuntu.cloud:server:<series_version>:<arch> For Example:
-com.ubuntu.cloud:server:14.04:amd64 Non-released images (eg beta, daily etc) have product ids like:
-com.ubuntu.cloud.daily:server:13.10:amd64
-
-The metadata index and product files are required to be in the following directory tree (relative to the URL associated with each path component):
-
-<path_url> |-streams |-v1 |-index.(s)json |-product-foo.(s)json |-product-bar.(s)json
-
-The index file must be called "index.(s)json" (sjson for signed). The various product files are named according to the Path values contained in the index file.
-
-Tools metadata uses a simplestreams content type of "content-download". The product id is formed as follows:
-
-"com.ubuntu.juju:<series_version>:<arch>"
-
-For example:
-
-"com.ubuntu.juju:12.04:amd64"
-
-The metadata index and product files are required to be in the following directory tree (relative to the URL associated with each path component). In addition, tools tarballs which Juju needs to download are also expected.
-
-|-streams | |-v1 | |-index.(s)json | |-product-foo.(s)json | |-product-bar.(s)json | |-releases |-tools-abc.tar.gz |-tools-def.tar.gz |-tools-xyz.tar.gz
-
-The index file must be called "index.(s)json" (sjson for signed). The product file and tools tarball name(s) match whatever is in the index/product files.
-
-### Configuration
-
-For supported public clouds, no extra configuration is required; things work out-of-the-box. However, for testing purposes, or for non-supported cloud deployments, Juju needs to know where to find the tools and which image to run. Even for supported public clouds where all required metadata is available, the user can put their own metadata in the search path to override what is provided by the cloud.
-
-#### User specified URLs
-
-These are initially specified in the environments.yaml file (and then subsequently copied to the jenv file when the environment is bootstrapped). For images, use "image-metadata-url"; for tools, use "tools-metadata-url". The URLs can point to a world readable container/bucket in the cloud, an address served by a http server, or even a shared directory which is accessible by all node instances running in the cloud.
-
-Assume an Apache http server with base URL `https://juju-metadata` , providing access to information at `<base>/images` and `<base>/tools` . The Juju environment yaml file could have the following entries (one or both):
-
-tools-metadata-url: https://juju-metadata/tools image-metadata-url: https://juju-metadata/images
-
-The required files in each location is as per the directory layout described earlier. For a shared directory, use a URL of the form "file:///sharedpath".
-
-#### Cloud storage
-
-If no matching metadata is found in the user specified URL, environment's cloud storage is searched. No user configuration is required here - all Juju environments are set up with cloud storage which is used to store state information, charms etc. Cloud storage setup is provider dependent; for Amazon and Openstack clouds, the storage is defined by the "control-bucket" value, for Azure, the "storage-account-name" value is relevant.
-
-The (optional) directory structure inside the cloud storage is as follows:
-
-|-tools | |-streams | |-v1 | |-releases | |-images |-streams |-v1
-
-Of course, if only custom image metadata is required, the tools directory will not be required, and vice versa.
-
-Note that if juju bootstrap is run with the `--upload-tools` option, the tools and metadata are placed according to the above structure. That's why the tools are then available for Juju to use.
-
-#### Provider specific storage
-
-Providers may allow additional locations to search for metadata and tools. For OpenStack, Keystone endpoints may be created by the cloud administrator. These are defined as follows:
-
-juju-tools the &LT;path_url&GT; value as described above in Tools Metadata Contentsproduct-streams the &LT;path_url&GT; value as described above in Image Metadata Contents
-
-Other providers may similarly be able to specify locations, though the implementation will vary.
-
-This is the default location used to search for image and tools metadata and is used if no matches are found earlier in any of the above locations. No user configuration is required.
-
-There are two main issues when deploying a private cloud:
-
-1. Image ids will be specific to the cloud.
-2. Often, outside internet access is blocked
-
-Issue 1 means that image id metadata needs to be generated and made available.
-
-Issue 2 means that tools need to be mirrored locally to make them accessible.
-
-Juju tools exist to help with generating and validating image and tools metadata. For tools, it is often easiest to just mirror `https://streams.canonical.com/tools` . However image metadata cannot be simply mirrored because the image ids are taken from the cloud storage provider, so this needs to be generated and validated using the commands described below.
-
-The available Juju metadata tools can be seen by using the help command:
-
-juju help metadata
-
-The overall workflow is:
-
-- Generate image metadata
-- Copy image metadata to somewhere in the metadata search path
-- Optionally, mirror tools to somewhere in the metadata search path
-- Optionally, configure tools-metadata-url and/or image-metadata-url
-
-#### Image metadata
-
-Generate image metadata using
-
-juju metadata generate-image -d <metadata_dir>
-
-As a minimum, the above command needs to know the image id to use and a directory in which to write the files.
-
-Other required parameters like region, series, architecture etc. are taken from the current Juju environment (or an environment specified with the -e option). These parameters can also be overridden on the command line.
-
-The image metadata command can be run multiple times with different regions, series, architecture, and it will keep adding to the metadata files. Once all required image ids have been added, the index and product json files can be uploaded to a location in the Juju metadata search path. As per the Configuration section, this may be somewhere specified by the `image-metadata-url` setting or the cloud's storage etc.
-
-Examples:
-
-1. image-metadata-url
-
-- upload contents of to `http://somelocation`
-- set image-metadata-url to `http://somelocation/images`
-
-2. Cloud storage
-
-If run without parameters, the validation command will take all required details from the current Juju environment (or as specified by -e) and output the image id it would use to spin up an instance. Alternatively, series, region, architecture etc. can be specified on the command line to override the values in the environment config.
-#### Tools metadata
-
-Generally, tools and related metadata are mirrored from `https://streams.canonical.com/tools` . However, it is possible to manually generate metadata for a custom built tools tarball.
-
-First, create a tarball of the relevant tools and place in a directory structured like this:
-
-<tools_dir>/tools/releases/
-
-Now generate relevant metadata for the tools by running the command:
-
-juju generate-tools -d <tools_dir>
-
-Finally, the contents of can be uploaded to a location in the Juju metadata search path. As per the Configuration section, this may be somewhere specified by the tools-metadata-url setting or the cloud's storage path settings etc.
-
-Examples:
-
-1. tools-metadata-url
-
-- upload contents of the tools dir to `http://somelocation`
-- set tools-metadata-url to `http://somelocation/tools`
-
-2. Cloud storage
-
-upload contents of directly to environment's cloud storage
-
-As with image metadata, the validation command is used to ensure tools are available for Juju to use:
-
-juju metadata validate-tools
-
-The same comments apply. Run the validation tool without parameters to use details from the Juju environment, or override values as required on the command line. See `juju help metadata validate-tools` for more details.
-
-##Appendix I - Using Tags
-##Appendix II - Using the MAAS CLI
-As well as the web interface, many tasks can be performed by accessing the MAAS API directly through the maas-cli command. This section details how to login with this tool and perform some common operations.
-
-###Logging in
-Before the API will accept any commands from maas-cli, you must first login. To do this, you need the API key which can be found in the user interface.
-
-Login to the web interface on your MAAS. Click on the username in the top right corner and select ‘Preferences’ from the menu which appears.
-
-![]maascli-prefs.png
-A new page will load...
-
-![]maascli-key.png
-The very first item is a list of MAAS keys. One will have already been generated when the system was installed. It’s easiest to just select all the text, copy the key (it’s quite long!) and then paste it into the commandline. The format of the login command is:
-
-```
- maas-cli login <profile-name> <hostname> <key>
-```
-
-The profile created is an easy way of associating your credentials with any subsequent call to the API. So an example login might look like this:
-
-```
-maas-cli login maas http://10.98.0.13/MAAS/api/1.0
-AWSCRMzqMNy:jjk...5e1FenoP82Qm5te2
-```
-which creates the profile ‘maas’ and registers it with the given key at the specified API endpoint. If you omit the credentials, they will be prompted for in the console. It is also possible to use a hyphen, ‘-‘ in place of the credentials. In this case a single line will be read from stdin, stripped of any whitespace and used as the credentials, which can be useful if you are devolping scripts for specific tasks. If an empty string is passed instead of the credentials, the profile will be logged in anonymously (and consequently some of the API calls will not be available)
-
-### maas-cli commands
-The maas-cli command exposes the whole API, so you can do anything you actually can do with MAAS using this command. This leaves us with a vast number of options, which are more fully expressed in the complete [2][MAAS Documentation]
-
-list:
-    lists the details [name url auth-key] of all the currently logged-in profiles.
-
-login <profile> <url> <key>:
-    Logs in to the MAAS controller API at the given URL, using the key provided and
-    associates this connection with the given profile name.
-
-logout <profile>:
-    Logs out from the given profile, flushing the stored credentials.
-
-refresh:
-    Refreshes the API descriptions of all the current logged in profiles. This may become necessary for example when upgrading the maas packages to ensure the command-line options match with the API.
-
-### Useful examples
-
-Displays current status of nodes in the commissioning phase:
-```
-maas cli maas nodes check-commissioning
-```
-
-Accept and commission all discovered nodes:
-```
-maas-cli maas nodes accept-all
-```
-
-List all known nodes:
-```
-maas-cli maas nodes list
-```
-
-Filter the list using specific key/value pairs:
-```
-maas-cli maas nodes list architecture="i386/generic"
-```
-
-Set the power parameters for an ipmi enabled node:
-```
-maas-cli maas node update <system_id> \
-  power_type="ipmi" \
-  power_parameters_power_address=192.168.22.33 \
-  power_parameters_power_user=root \
-  power_parameters_power_pass=ubuntu;
-```
-## Appendix III - Physical Zones
-
-To help you maximise fault-tolerance and performance of the services you deploy, MAAS administrators can define _physical zones_ (or just _zones_ for short), and assign nodes to them. When a user requests a node, they can ask for one that is in a specific zone, or one that is not in a specific zone.
-
-It's up to you as an administrator to decide what a physical zone should represent: it could be a server rack, a room, a data centre, machines attached to the same UPS, or a portion of your network. Zones are most useful when they represent portions of your infrastructure. But you could also use them simply to keep track of where your systems are located.
-
-Each node is in one and only one physical zone. Each MAAS instance ships with a default zone to which nodes are attached by default. If you do not need this feature, you can simply pretend it does not exist.
-
-### Applications
-
-Since you run your own MAAS, its physical zones give you more flexibility than those of a third-party hosted cloud service. That means that you get to design your zones and define what they mean. Below are some examples of how physical zones can help you get the most out of your MAAS.
-
-### Creating a Zone
-
-Only administrators can create and manage zones. To create a physical zone in the web user interface, log in as an administrator and browse to the "Zones" section in the top bar. This will takes you to the zones listing page. At the bottom of the page is a button for creating a new zone:
-
-![]add-zone.png
-
-Or to do it in the [_region-controller API_][#region-controller-api], POST your zone definition to the _"zones"_ endpoint.
-
-### Assigning Nodes to a Zone
-
-Once you have created one or more physical zones, you can set nodes' zones from the nodes listing page in the UI. Select the nodes for which you wish to set a zone, and choose "Set physical zone" from the "Bulk action" dropdown list near the top. A second dropdown list will appear, to let you select which zone you wish to set. Leave it blank to clear nodes' physical zones. Clicking "Go" will apply the change to the selected nodes.
-
-You can also set an individual node's zone on its "Edit node" page. Both ways are available in the API as well: edit an individual node through a request to the node's URI, or set the zone on multiple nodes at once by calling the operation on the endpoint.
-
-### Allocating a Node in a Zone
-
-To deploy in a particular zone, call the method in the [_region-controller API_][#region-controller-api] as before, but pass the parameter with the name of the zone. The method will allocate a node in that zone, or fail with an HTTP 409 ("conflict") error if the zone has no nodes available that match your request.
-
-Alternatively, you may want to request a node that is _not_ in a particular zone, or one that is not in any of several zones. To do that, specify the parameter to . This parameter takes a list of zone names; the allocated node will not be in any of them. Again, if that leaves no nodes available that match your request, the call will return a "conflict" error.
-
-It is possible, though not usually useful, to combine the and parameters. If your choice for is also present in , no node will ever match your request. Or if it's not, then the values will not affect the result of the call at all.
-
 
=== removed file 'Intro.md'
--- Intro.md	2014-04-11 14:51:27 +0000
+++ Intro.md	1970-01-01 00:00:00 +0000
@@ -1,26 +0,0 @@
-#Ubuntu Cloud Documentation
-
-## Deploying Production Grade OpenStack with MAAS, Juju and Landscape
-
-This documentation has been created to describe best practice in deploying
-a Production Grade installation of OpenStack using current Canonical 
-technologies, including bare metal provisioning using MAAS, service 
-orchestration with Juju and system management with Landscape.
-
-This documentation is divided into four main topics:
-
- 1. [Installing the MAAS Metal As A Service software](../installing-maas.html)
- 2. [Installing Juju and configuring it to work with MAAS](../installing-juju.html)
- 3. [Using Juju to deploy OpenStack](../installing-openstack.html)
- 4. [Deploying Landscape to manage your OpenStack cloud](../installing-landscape)
- 
-Once you have an up and running OpenStack deployment, you should also read
-our [Administration Guide](../admin-intro.html) which details common tasks
-for maintenance and scaling of your service. 
-
-
-## Legal notices
-
-
-
-![Canonical logo](./media/logo-canonical_no™-aubergine-hex.jpg)
 
=== removed file 'Logging-Juju.md'
--- Logging-Juju.md	2014-04-02 16:18:10 +0000
+++ Logging-Juju.md	1970-01-01 00:00:00 +0000
@@ -1,24 +0,0 @@
-Title: Logging - Juju
-Status: In Progress
-
-# Logging - Juju
-
-## Introduction
-
-**TODO**
-
-## Scope
-
-**TODO**
-
-## Connecting to rsyslogd
-
-Juju already uses `rsyslogd` for the aggregation of all logs into on centralized log. The
-target of this logging is the file `/var/log/juju/all-machines.log`. You can directly
-access it using the command
-
-````
-$ juju debug-log
-````
-
-**TODO** Describe a way to redirect this log to a central rsyslogd server.
 
=== removed file 'Logging-OpenStack.md'
--- Logging-OpenStack.md	2014-04-02 16:18:10 +0000
+++ Logging-OpenStack.md	1970-01-01 00:00:00 +0000
@@ -1,92 +0,0 @@
-Title: Logging - OpenStack
-Status: In Progress
-
-# Logging - OpenStack
-
-## Introduction
-
-**TODO**
-
-## Scope
-
-**TODO**
-
-## Connecting to rsyslogd
-
-By default OpenStack is writting its logging output into files into directories for each
-component, like `/var/log/nova` or `/var/log/glance`. For the usage of `rsyslogd` the components
-have to be configured to also log to `syslog`. When doing this also configure each component
-to log into a different syslog facility. This will help you to split the logs into individual
-components on the central logging server. So ensure the following settings:
-
-**/etc/nova/nova.conf:**
-
-````
-use_syslog=True
-syslog_log_facility=LOG_LOCAL0
-````
-
-**/etc/glance/glance-api.conf and /etc/glance/glance-registry.conf:**
-
-````
-use_syslog=True
-syslog_log_facility=LOG_LOCAL1
-````
-
-**/etc/cinder/cinder.conf:**
-
-````
-use_syslog=True
-syslog_log_facility=LOG_LOCAL2
-````
-
-**/etc/keystone/keystone.conf:**
-
-````
-use_syslog=True
-syslog_log_facility=LOG_LOCAL3
-````
-
-The object storage Swift be fault already logs to syslog. So you now can tell the local
-rsyslogd clients to pass the logged information to the logging server. You'll do this
-by creating a `/etc/rsyslog.d/client.conf` containing the line like
-
-````
-*.* @192.16.1.10
-````
-
-where the IP address points to your rsyslogd server. Best is to choose a server that is
-dedicated to this task only. Here you've got to create the file `/etc/rsyslog.d/server.conf`
-contining the settings
-
-````
-# Enable UDP
-$ModLoad imudp
-# Listen on 192.168.1.10 only
-$UDPServerAddress 192.168.1.10
-# Port 514
-$UDPServerRun 514
-# Create logging templates for nova
-$template NovaFile,"/var/log/rsyslog/%HOSTNAME%/nova.log"
-$template NovaAll,"/var/log/rsyslog/nova.log"
-# Log everything else to syslog.log
-$template DynFile,"/var/log/rsyslog/%HOSTNAME%/syslog.log"
-*.* ?DynFile
-# Log various openstack components to their own individual file
-local0.* ?NovaFile
-local0.* ?NovaAll
-& ~
-````
-
-This example only contains the settings for Nova only, the other OpenStack components
-have to be added the same way. Using two templates per component, one containing the 
-`%HOSTNAME%` variable and one without it enables a better splitting of the logged 
-data. Think about the two example nodes `alpha.example.com` and `bravo.example.com`.
-They will write their logging into the files
-
-- `/var/log/rsyslog/alpha.example.com/nova.log` - only the data of alpha,
-- `/var/log/rsyslog/bravo.example.com/nova.log` - only the data of bravo,
-- `/var/log/rsyslog/nova.log` - the combined data of both.
-
-This allows a quick overview over all nodes as well as the focussed analysis of an
-individual node.
 
=== removed file 'Logging.md'
--- Logging.md	2014-04-02 16:18:10 +0000
+++ Logging.md	1970-01-01 00:00:00 +0000
@@ -1,15 +0,0 @@
-Title: Logging
-Status: In Progress
-
-# Logging
-
-The controlling of individual logs is a cumbersome job, even in an environment with only
-few computer system. But it's even more worse in typical clouds with a large number of
-nodes. Here the centrallized approach using `rsyslogd` helps. It allows you to aggregate
-the logging output of all systems in one place. Here the monitoring and analysis gets
-more simple.
-
-Ubuntu uses `rsyslogd` as the default logging service. Since it is natively able to send 
-logs to a remote location, you don't have to install anything extra to enable this feature, 
-just modify the configuration file. In doing this, consider running your logging over 
-a management network or using an encrypted VPN to avoid interception.
 
=== removed file 'Scaling-Ceph.md'
--- Scaling-Ceph.md	2014-04-07 13:23:30 +0000
+++ Scaling-Ceph.md	1970-01-01 00:00:00 +0000
@@ -1,36 +0,0 @@
-Title: Scaling - Ceph
-Status: In Progress
-
-# Scaling - Ceph
-
-## Introduction
-
-Beside the redundancy for more safety and the higher performance through the usage of 
-Ceph as storage backend for OpenStack the user also benefits from the more simple way
-of scaling the storage of the needs grow.
-
-## Scope
-
-**TODO**
-
-## Scaling
-
-The addition of Ceph nodes is done using the Juju `add-node` command. By default
-it adds only one node, but it is possible to add the number of wanted nodes as
-argument. To add one more Ceph OSD Daemon node you simply call
-
-```
-juju add-node ceph-osd
-```
-
-Larger numbers of nodes can be added using the `-n` argument, e.g. 5 nodes
-with
-
-```
-juju add-node -n 5 ceph-osd
-```
-
-**Attention:** The adding of more nodes to Ceph leads to a redistribution of data
-between the nodes of an image. This can cause inefficiencies during this process. So
-it should be done in smaller steps.
-
 
=== removed file 'Upgrading-and-Patching-Juju.md'
--- Upgrading-and-Patching-Juju.md	2014-04-02 16:18:10 +0000
+++ Upgrading-and-Patching-Juju.md	1970-01-01 00:00:00 +0000
@@ -1,45 +0,0 @@
-Title: Upgrading and Patching - Juju
-Status: In Progress
-
-# Upgrading and Patching - Juju
-
-## Introduction
-
-**TODO**
-
-## Scope
-
-**TODO**
-
-## Upgrading
-
-The upgrade of a Juju environment is done using the Juju client and its command
-
-````
-$ juju upgrade-juju
-````
-
-This command sets the version number for all Juju agents to run. This by default
-is the most recent supported version compatible with the comand-line tools version.
-So ensure that you've upgraded the Juju client first.
-
-When run without arguments, `upgrade-juju` will try to upgrade to the following 
-versions, in order of preference and depending on the current value of the 
-environment's `agent-version` setting:
-
-- The highest patch.build version of the *next* stable major.minor version.
-- The highest patch.build version of the *current* major.minor version.
-
-Both of these depend on the availability of the according tools. On MAAS you've
-got to manage this yourself using the command
-
-````
-$ juju sync-tools
-````
-
-This copies the Juju tools tarball from the official tools store (located
-at https://streams.canonical.com/juju) into your environment.
-
-## Patching
-
-**TODO**
 
=== removed file 'Upgrading-and-Patching-OpenStack.md'
--- Upgrading-and-Patching-OpenStack.md	2014-04-02 16:18:10 +0000
+++ Upgrading-and-Patching-OpenStack.md	1970-01-01 00:00:00 +0000
@@ -1,83 +0,0 @@
-Title: Upgrading and Patching - OpenStack
-Status: In Progress
-
-# Upgrading and Patching - OpenStack
-
-## Introduction
-
-**TODO**
-
-## Scope
-
-**TODO**
-
-## Upgrading
-
-The upgrade of an OpenStack cluster in one big step is an approach requiring additional
-hardware to setup an update cloud beside the productive one and leads to a longer
-outage while your cloud is in read-only mode, the state is transferred to the new
-one and the environments are switched. So the preferred way of upgrading an OpenStack
-cloud is the rolling upgrade of each component of the system piece by piece.
-
-Here you can choose between in-place and side-by-side upgrades. But the first one needs
-to shutdown the regarding component while you're performing its upgrade. Additionally you
-may have troubles in case of a rollback. So to avoid this the side by side upgrade is
-the preferred way here.
-
-Before starting the upgrade itself you should
-
-- Perform some "cleaning" of the environment process to ensure a consistent state; for 
-  example, instances not fully purged from the system after deletion may cause 
-  indeterminate behavior
-- Read the release notes and documentation
-- Find incompatibilities between your versions
-
-The upgrade tasks here follow the same procedure for each component:
-
-1. Configure the new worker
-1. Turn off the current worker; during this time hide the downtime using a message
-   queue or a load balancer
-1. Take a backup as described earlier of the old worker for a rollback
-1. Copy the state of the current to the new worker
-1. Start up the new worker
-
-Now repeat these steps for each worker in an approprate order. In case of a problem it
-should be easy to rollback as long as the former worker stays untouched. This is,
-beside the shorter downtime, the most important advantage of the side-by-side upgrade.
-
-The following order for service upgrades seems the most successful:
-
-1. Upgrade the OpenStack Identity Service (Keystone).
-1. Upgrade the OpenStack Image Service (Glance).
-1. Upgrade OpenStack Compute (Nova), including networking components.
-1. Upgrade OpenStack Block Storage (Cinder).
-1. Upgrade the OpenStack dashboard.
-
-These steps look very easy, but still are a complex procedure depending on your cloud
-configuration. So we recommend to have a testing environment with a near-identical
-architecture to your production system. This doesn't mean that you should use the same
-sizes and hardware, which would be best but expensive. But there are some ways to reduce
-the cost.
-
-- Use your own cloud. The simplest place to start testing the next version of OpenStack 
-  is by setting up a new environment inside your own cloud. This may seem odd—especially 
-  the double virtualisation used in running compute nodes—but it's a sure way to very 
-  quickly test your configuration.
-- Use a public cloud. Especially because your own cloud is unlikely to have sufficient 
-  space to scale test to the level of the entire cloud, consider using a public cloud 
-  to test the scalability limits of your cloud controller configuration. Most public 
-  clouds bill by the hour, which means it can be inexpensive to perform even a test 
-  with many nodes.
-- Make another storage endpoint on the same system. If you use an external storage plug-in 
-  or shared file system with your cloud, in many cases it's possible to test that it 
-  works by creating a second share or endpoint. This will enable you to test the system 
-  before entrusting the new version onto your storage.
-- Watch the network. Even at smaller-scale testing, it should be possible to determine 
-  whether something is going horribly wrong in intercomponent communication if you 
-  look at the network packets and see too many.
-
-**TODO** Add more concrete description here.
-
-## Patching
-
-**TODO**
 
=== removed directory 'build'
=== removed directory 'build/epub'
=== removed directory 'build/html'
=== removed directory 'build/pdf'
=== removed file 'installing-openstack-outline.md'
--- installing-openstack-outline.md	2014-04-11 14:51:27 +0000
+++ installing-openstack-outline.md	1970-01-01 00:00:00 +0000
@@ -1,395 +0,0 @@
-Title:Installing OpenStack
-
-# Installing OpenStack
-
-![Openstack](../media/openstack.png)
-
-##Introduction
-
-OpenStack is a versatile, open source cloud environment equally suited to serving up public, private or hybrid clouds. Canonical is a Platinum Member of the OpenStack foundation and has been involved with the OpenStack project since its inception; the software covered in this document has been developed with the intention of providing a streamlined way to deploy and manage OpenStack installations.
-
-### Scope of this documentation
-
-The OpenStack platform is powerful and its uses diverse. This section of documentation 
-is primarily concerned with deploying a 'standard' running OpenStack system using, but not limited to, Canonical components such as MAAS, Juju and Ubuntu. Where appropriate other methods and software will be mentioned.
-
-### Assumptions
-
-1. Use of MAAS
-   This document is written to provide instructions on how to deploy OpenStack using MAAS for hardware provisioning. If you are not deploying directly on hardware, this method will still work, with a few alterations, assuming you have a properly configured Juju environment. The main difference will be that you will have to provide different configuration options depending on the network configuration.
-   
-2. Use of Juju
-   This document assumes an up to date, stable release version of Juju.
-   
-3. Local network configuration
-   This document assumes that you have an adequate local network configuration, including separate interfaces for access to the OpenStack cloud. Ideal networks are laid out in the [MAAS][MAAS documentation for OpenStack]
-
-## Planning an installation
-
-Before deploying any services, it is very useful to take stock of the resources available and how they are to be used. OpenStack comprises of a number of interrelated services (Nova, Swift, etc) which each have differing demands in terms of hosts. For example, the Swift service, which provides object storage, has a different requirement than the Nova service, which provides compute resources.
-
-The minimum requirements for each service and recommendations are laid out in the official [oog][OpenStack Operations Guide] which is available (free) in HTML or various downloadable formats. For guidance, the following minimums are recommended for Ubuntu Cloud:
-
-[insert minimum hardware spec]
-
-
-
-The recommended composition of nodes for deploying OpenStack with MAAS and Juju is that all nodes in the system should be capable of running *ANY* of the services. This is best practice for the robustness of the system, as since any physical node should fail, another can be repurposed to take its place. This obviously extends to any hardware requirements such as extra network interfaces.
-
-If for reasons of economy or otherwise you choose to use different configurations of hardware, you should note that your ability to overcome hardware failure will be reduced. It will also be necessary to target deployments to specific nodes - see the section in the MAAS documentation on tags [MAAS tags]
-
-
-###Create the OpenStack configuration file
-
-We will be using Juju charms to deploy the component parts of OpenStack. Each charm encapsulates everything required to set up a particular service. However, the individual services have many configuration options, some of which we will want to change. 
-
-To make this task easier and more reproduceable, we will create a separate configuration file with the relevant options for all the services. This is written in a standard YAML format. 
-
-You can download the [openstack-config.yaml] file we will be using from here. It is also reproduced below:
-
-```
-keystone:
-  admin-password: openstack
-  debug: 'true'
-  log-level: DEBUG
-nova-cloud-controller:
-  network-manager: 'Neutron'
-  quantum-security-groups: 'yes'
-  neutron-external-network: Public_Network
-nova-compute:
-  enable-live-migration: 'True'
-  migration-auth-type: "none"
-  virt-type: kvm
-  #virt-type: lxc
-  enable-resize: 'True'
-quantum-gateway:
-  ext-port: 'eth1'
-  plugin: ovs
-glance:
-  ceph-osd-replication-count: 3
-cinder:
-  block-device: None
-  ceph-osd-replication-count: 3
-  overwrite: "true"
-  glance-api-version: 2
-ceph:
-  fsid: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
-  monitor-secret: AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==
-  osd-devices: /dev/sdb
-  osd-reformat: 'True'
-```
-
-For all services, we can configure the `openstack-origin` to point to an install source. In this case, we will rely on the default, which will point to the relevant sources for the Ubuntu 14.04 LTS Trusty release. Further configuration for each service is explained below:
-
-####keystone
-admin password:
-    You should set a memorable password here to be able to access OpenStack when it is deployed
-
-debug: 
-    It is useful to set this to 'true' initially, to monitor the setup. this will produce more verbose messaging.
-   
-log-level: 
-    Similarly, setting the log-level to DEBUG means that more verbose logs can be generated. These options can be changed once the system is set up and running normally. 
-
-####nova-cloud-controller
-
-cloud-controller:
-    'Neutron' - Other options are now depricated.
-    
-quantum-security-groups: 
-    'yes'
-    
-neutron-external-network: 
-    Public_Network - This is an interface we will use for allowing access to the cloud, and will be defined later
-
-####nova-compute
-enable-live-migration: 
-  We have set this to 'True'
-
-migration-auth-type: 
-    "none"
-
-virt-type: 
-    kvm
-
-enable-resize: 
-    'True'
-
-####quantum-gateway
-ext-port:
-    This is where we specify the hardware for the public network. Use 'eth1' or the relevant 
-  plugin: ovs
-  
-  
-####glance
-
-  ceph-osd-replication-count: 3
-
-####cinder
-  openstack-origin: cloud:trusty-icehouse/updates
-  block-device: None
-  ceph-osd-replication-count: 3
-  overwrite: "true"
-  glance-api-version: 2
-  
-####ceph
-  
-fsid: 
-    The fsid is simply a unique identifier. You can generate a suitable value by running `uuidgen`  which should return a value which looks like: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
-    
-monitor-secret: 
-    The monitor secret is a secret string used to authenticate access. There is advice on how to generate a suitable secure secret at [ceph][the ceph website]. A typical value would be `AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==`
-    
-osd-devices: 
-    This should point (in order of preference) to a device,partition or filename. In this case we will assume secondary device level storage located at `/dev/sdb`
-    
-osd-reformat: 
-    We will set this to 'True', allowing ceph to reformat the drive on provisioning. 
-    
-  
-##Deploying OpenStack with Juju
-Now that the configuration is defined, we can use Juju to deploy and relate the services.
-
-###Initialising Juju
-Juju requires a minimal amount of setup. Here we assume it has already been configured to work with your MAAS cluster (see the [juju_install][Juju Install Guide] for more information on this.
-
-Firstly, we need to fetch images and tools that Juju will use:
-```
-juju sync-tools --debug
-```
-Then we can create the bootstrap instance:
-
-```
-juju bootstrap --upload-tools --debug
-```
-We use the upload-tools switch to use the local versions of the tools which we just fetched. The debug switch will give verbose output which can be useful. This process may take a few minutes, as Juju is creating an instance and installing the tools. When it has finished, you can check the status of the system with the command:
-```
-juju status
-```
-This should return something like:
-```
----------- example 
-```
-### Deploy the OpenStack Charms
-
-Now that the Juju bootstrap node is up and running we can deploy the services required to make our OpenStack installation. To configure these services properly as they are deployed, we will make use of the configuration file we defined earlier, by passing it along with the `--config` switch with each deploy command. Substitute in the name and path of your config file if different.
-
-It is useful but not essential to deploy the services in the order below. It is also highly reccommended to open an additional terminal window and run the command `juju debug-log`. This will output the logs of all the services as they run, and can be useful for troubleshooting.
-
-It is also recommended to run a `juju status` command periodically, to check that each service has been installed and is running properly. If you see any errors, please consult the [troubleshooting][troubleshooting section below].
-
-```
-juju deploy --to=0 juju-gui
-juju deploy rabbitmq-server
-juju deploy mysql
-juju deploy --config openstack-config.yaml openstack-dashboard
-juju deploy --config openstack-config.yaml keystone
-juju deploy --config openstack-config.yaml ceph -n 3
-juju deploy --config openstack-config.yaml nova-compute -n 3
-juju deploy --config openstack-config.yaml quantum-gateway
-juju deploy --config openstack-config.yaml cinder
-juju deploy --config openstack-config.yaml nova-cloud-controller
-juju deploy --config openstack-config.yaml glance
-juju deploy --config openstack-config.yaml ceph-radosgw
-```
-
-
-### Add relations between the OpenStack services
-
-Although the services are now deployed, they are not yet connected together. Each service currently exists in isolation. We use the `juju add-relation`command to make them aware of each other and set up any relevant connections and protocols. This extra configuration is taken care of by the individual charms themselves. 
-
-    
-We should start adding relations between charms by setting up the Keystone authorization service and its database, as this will be needed by many of the other connections:
-
-juju add-relation keystone mysql
-
-We wait until the relation is set. After it finishes check it with juju status:
-
-```
-juju status mysql
-juju status keystone
-```
-
-It can take a few moments for this service to settle. Although it is certainly possible to continue adding relations (Juju manages a queue for pending actions) it can be counterproductive in terms of the overall time taken, as many of the relations refer to the same services.
-The following relations also need to be made:
-```
-juju add-relation nova-cloud-controller mysql
-juju add-relation nova-cloud-controller rabbitmq-server
-juju add-relation nova-cloud-controller glance
-juju add-relation nova-cloud-controller keystone
-juju add-relation nova-compute mysql
-juju add-relation nova-compute rabbitmq-server
-juju add-relation nova-compute glance
-juju add-relation nova-compute nova-cloud-controller
-juju add-relation glance mysql
-juju add-relation glance keystone
-juju add-relation cinder keystone
-juju add-relation cinder mysql
-juju add-relation cinder rabbitmq-server
-juju add-relation cinder nova-cloud-controller
-juju add-relation openstack-dashboard keystone
-juju add-relation swift-proxy swift-storage
-juju add-relation swift-proxy keystone
-```
-Finally, the output of juju status should show the all the relations as complete. The OpenStack cloud is now running, but it needs to be populated with some additional components before it is ready for use.
-
-
-
-
-##Preparing OpenStack for use
-
-###Configuring access to Openstack
-
-
-
-The configuration data for OpenStack can be fetched by reading the configuration file generated by the Keystone service. You can also copy this information by logging in to the Horizon (OpenStack Dashboard) service and examining the configuration there. However, we actually need only a few bits of information. The following bash script can be run to extract the relevant information:
-
-```
-#!/bin/bash
-
-set -e
-
-KEYSTONE_IP=`juju status keystone/0 | grep public-address | awk '{ print $2 }' | xargs host | grep -v alias | awk '{ print $4 }'`
-KEYSTONE_ADMIN_TOKEN=`juju ssh keystone/0 "sudo cat /etc/keystone/keystone.conf | grep admin_token" | sed -e '/^M/d' -e 's/.$//' | awk '{ print $3 }'`
-
-echo "Keystone IP: [${KEYSTONE_IP}]"
-echo "Keystone Admin Token: [${KEYSTONE_ADMIN_TOKEN}]"
-
-cat << EOF > ./nova.rc
-export SERVICE_ENDPOINT=http://${KEYSTONE_IP}:35357/v2.0/
-export SERVICE_TOKEN=${KEYSTONE_ADMIN_TOKEN}
-export OS_AUTH_URL=http://${KEYSTONE_IP}:35357/v2.0/
-export OS_USERNAME=admin
-export OS_PASSWORD=openstack
-export OS_TENANT_NAME=admin
-EOF
-
-juju scp ./nova.rc nova-cloud-controller/0:~
-```  
-This script extract the required information and then copies the file to the instance running the nova-cloud-controller.
-Before we do any nova or glance command we will load the file we just created:
-
-```
-$ source ./nova.rc
-$ nova endpoints
-```
-
-At this point the output of nova endpoints should show the information of all the available OpenStack endpoints.
-
-### Install the Ubuntu Cloud Image
-
-In order for OpenStack to create instances in its cloud, it needs to have access to relevant images
-$ mkdir ~/iso
-$ cd ~/iso
-$ wget http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
-
-###Import the Ubuntu Cloud Image into Glance
-!!!Note:  glance comes with the package glance-client which may need to be installed where you plan the run the command from
-
-```
-apt-get install glance-client
-glance add name="Trusty x86_64" is_public=true container_format=ovf disk_format=qcow2 < trusty-server-cloudimg-amd64-disk1.img
-```
-###Create OpenStack private network
-Note:  nova-manage  can be run from the nova-cloud-controller node or any of the nova-compute nodes. To access the node we run the following command:
-
-```
-juju ssh nova-cloud-controller/0
-
-sudo nova-manage network create --label=private --fixed_range_v4=1.1.21.32/27 --num_networks=1 --network_size=32 --multi_host=T --bridge_interface=eth0 --bridge=br100
-```
-
-To make sure that we have created the network we can now run the following command:
-
-```
-sudo nova-manage network list
-```
-
-### Create OpenStack public network
-```
-sudo nova-manage floating create --ip_range=1.1.21.64/26
-sudo nova-manage floating list
-```
-Allow ping and ssh access adding them to the default security group
-Note: The following commands are run from a machine where we have the package python-novaclient installed and within a session where we have loaded the above created nova.rc file.
-
-```
-nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
-nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
-```
-
-###Create and register the ssh keys in OpenStack
-Generate a default keypair
-```
-ssh-keygen -t rsa -f ~/.ssh/admin-key
-```
-###Copy the public key into Nova
-We will name it admin-key:
-Note: In the precise version of python-novaclient the command works with --pub_key instead of --pub-key
-
-```
-nova keypair-add --pub-key ~/.ssh/admin-key.pub admin-key
-```
-And make sure it’s been successfully created:
-```
-nova keypair-list
-```
-
-###Create a test instance
-We created an image with glance before. Now we need the image ID to start our first instance. The ID can be found with this command:
-```
-nova image-list
-```
-
-Note: we can also use the command glance image-list
-###Boot the instance:
-
-```
-nova boot --flavor=m1.small --image=< image_id_from_glance_index > --key-name admin-key testserver1
-```
-
-###Add a floating IP to the new instance
-First we allocate a floating IP from the ones we created above:
-
-```
-nova floating-ip-create
-```
-
-Then we associate the floating IP obtained above to the new instance:
-
-```
-nova add-floating-ip 9363f677-2a80-447b-a606-a5bd4970b8e6  1.1.21.65
-```
-
-
-### Create and attach a Cinder volume to the instance
-Note: All these steps can be also done through the Horizon Web UI
-
-We make sure that cinder works by creating a 1GB volume and attaching it to the VM:
-
-```
-cinder create --display_name test-cinder1 1
-```
-
-Get the ID of the volume with cinder list:
-
-```
-cinder list
-```
-
-Attach it to the VM as vdb
-
-```
-nova volume-attach test-server1 bbb5c5c2-a5fd-4fe1-89c2-d16fe91578d4 /dev/vdb
-```
-
-Now we should be able to ssh the VM test-server1 from a server with the private key we created above and see that vdb appears in /proc/partitions
-
-
-
-
-[troubleshooting]
-[oog](http://docs.openstack.org/ops/)
-[MAAS tags]
-[openstack-config.yaml]
-[ceph](http://ceph.com/docs/master/dev/mon-bootstrap/)
 
=== removed file 'landcsape.md'
--- landcsape.md	2014-03-24 13:49:58 +0000
+++ landcsape.md	1970-01-01 00:00:00 +0000
@@ -1,1297 +0,0 @@
-#Managing OpenStack with Landscape
-
-##About Landscape
-Landscape is a system management tool designed to let you easily manage multiple Ubuntu systems - up to 40,000 with a single Landscape instance. From a single dashboard you can apply package updates and perform other administrative tasks on many machines. You can categorize machines by group, and manage each group separately. You can make changes to targeted machines even when they are offline; the changes will be applied next time they start. Landscape lets you create scripts to automate routine work such as starting and stopping services and performing backups. It lets you use both common Ubuntu repositories and any custom repositories you may create for your own computers. Landscape is particularly adept at security updates; it can highlight newly available packages that involve security fixes so they can be applied quickly. You can use Landscape as a hosted service as part of Ubuntu Advantage, or run it on premises via Landscape Dedicated Server.
-
-##Ubuntu Advantage
-Ubuntu Advantage comprises systems management tools, technical support, access to online resources and support engineers, training, and legal assurance to keep organizations on top of their Ubuntu server, desktop, and cloud deployments. Advantage provides subscriptions at various support levels to help organizations maintain the level of support they need.
-
-##Concepts
-
-###Tags
-
-
-Landscape lets you group multiple computers by applying tags to them.
-You can group computers using any set of characteristics; architecture
-and location might be two logical tagging schemes. Tag names may use any
-combination of letters, numbers, and dashes. Each computer can be
-associated with multiple tags. There is no menu choice for tags; rather,
-you can select multiple computers under the COMPUTERS menu and apply or
-remove one or more tags to all the ones you select on the INFO screen.
-If you want to specify more than one tag at a time for your selected
-computers, separate the tags by spaces.
-
-###Packages
-
-In Linux, a package is a group of related files for an application that
-make it easy to install, upgrade, and remove the application. You can
-manage packages from the PACKAGES menu under COMPUTERS.
-
-###Repositories
-
-Linux distributions like Ubuntu use repositories to hold packages you
-can install on managed computers. While Ubuntu has [several
-repositories](https://help.ubuntu.com/community/Repositories/Ubuntu/)
-that anyone can access, you can also maintain your own repositories on
-your network. This can be useful when you want to maintain packages with
-different versions from those in the community repositories, or if
-you've packages in-house software for installation. Landscape's [12.09
-release
-notes](https://help.landscape.canonical.com/LDS/ReleaseNotes12.09#Repository_Management)
-contain a quick tutorial about repository management.
-
-###Upgrade profiles
-
-An upgrade profile defines a schedule for the times when upgrades are to
-be automatically installed on the machines associated with a specific
-access group. You can associate zero or more computers with each upgrade
-profile via tags to install packages on those computers. You can also
-associate an upgrade profile with an access group, which limits its use
-to only computers within the specified access group. You can manage
-upgrade profiles from the UPGRADE PROFILES link in the PROFILES choice
-under your account.
-
-###Package profiles
-
-A package profile, or meta-package, comprises a set of one or more
-packages, including their dependencies and conflicts (generally called
-constraints), that you can manage as a group. Package profiles specify
-sets of packages that associated systems should always get, or never
-get. You can associate zero or more computers with each package profile
-via tags to install packages on those computers. You can also associate
-a package profile with an access group, which limits its use to only
-computers within the specified access group. You can manage package
-profiles from the Package Profiles link in the PROFILES menu under your
-account.
-
-###Removal profiles
-
-A removal profile defines a maximum number of days that a computer can
-go without exchanging data with the Landscape server before it is
-automatically removed. If more days pass than the profile's "Days
-without exchange", that computer will automatically be removed and the
-license seat it held will be released. This helps Landscape keep license
-seats open and ensure Landscape is not tracking stale or retired
-computer data for long periods of time. You can associate zero or more
-computers with each removal profile via tags to ensure those computers
-are governed by this removal profile. You can also associate a removal
-profile with an access group, which limits its use to only computers
-within the specified access group. You can manage removal profiles from
-the REMOVAL PROFILES link in the PROFILES choice under your account.
-
-Scripts
--------
-
-Landscape lets you run scripts on the computers you manage in your
-account. The scripts may be in any language, as long as an interpreter
-for that language is present on the computers on which they are to run.
-You can maintain a library of scripts for common tasks. You can manage
-scripts from the STORED SCRIPTS menu under your account, and run them
-against computers from the SCRIPTS menu under COMPUTERS.
-
-Administrators
---------------
-
-Administrators are people who are authorized to manage computers using
-Landscape. You can manage administrators from the ADMINISTRATORS menu
-under your account.
-
-Access Groups
--------------
-
-Landscape lets administrators limit administrative rights on computers
-by assigning them to logical groupings called access groups. Each
-computer can be in only one access group. Typical access groups might be
-constucted around organizational units or departments, locations, or
-hardware architecture. You can manage access groups from the ACCESS
-GROUPS menu under your account; read about [how to create access
-groups](https://landscape.canonical.com/static/doc/user-guide/ch05.html#creatingaccessgroups "Creating access groups"),
-[add computers to access
-groups](https://landscape.canonical.com/static/doc/user-guide/ch05.html#addingtoaccessgroups "Adding computers to access groups"),
-and [associate administrators with access
-groups](https://landscape.canonical.com/static/doc/user-guide/ch05.html#associatingadmins "Associating roles with access groups").
-It is good policy to come up with and document a naming convention for
-access groups before you deploy Landscape, so that all administrators
-understand what constitutes an acceptable logical grouping for your
-organization.
-
-Roles
------
-
-For each access group, you can assign management privileges to
-administrators via the use of roles. Administrators may be associated
-with multiple roles, and roles may be associated with many access
-groups. You can manage roles from the ROLES menu under your account.
-
-Alerts
-------
-
-Landscape uses alerts to notify administrators of conditions that
-require attention. You can manage alerts from the ALERTS menu under your
-account.
-
-Provisioning
-------------
-
-Landscape lets you provision new computers starting with bare hardware -
-what Canonical calls metal as a service. With MAAS, you provision new
-hardware only as you need it, just as you would bring new cloud
-instances online. [The Ubuntu wiki explains how to set up
-MAAS](https://wiki.ubuntu.com/ServerTeam/MAAS/).
-
-You can provision one or more new computers from the PROVISIONING menu
-under your account.
-
-
-##Managing Landscape
-------------------
-
-
-Prerequisites
--------------
-
-You can install Landscape Dedicated Server (LDS) on any server with a
-dual-core processor running at 2.0GHz or higher, at least 4GB of RAM,
-and 5GB of disk space. The operating system must be Ubuntu Server 12.04
-LTS x86\_64 or higher. You must also have PostgreSQL installed and
-network ports 80/tcp (http) and 443/tcp (https) open. You can optionally
-open port 22/tcp (ssh) as well for general server maintenance.
-
-Installing
-----------
-
-Refer to the [Recommended
-Deployment](https://help.landscape.canonical.com/LDS/RecommendedDeployment)
-guide in the Landscape wiki for all the information you need to install,
-configure, and start Landscape and the dependent services it relies on.
-
-Upgrading Landscape
--------------------
-
-The process of upgrading an installed version of Landscape is
-[documented in the Landscape
-wiki](https://help.landscape.canonical.com/LDS/ReleaseNotes#Upgrading).
-
-Backing up and restoring
-------------------------
-
-Landscape uses several PostgreSQL databases and needs to keep them
-consistent. For example, if you remove a computer from Landscape
-management, more than one database needs to be updated. Running a
-utility like `pg_dumpall`{.code} won't guarantee the consistency of the
-backup, because while the dump process does lock all tables in the
-database being backed up, it doesn't care about other databases. The
-result will likely be an inconsistent backup.
-
-Instead, you should perform hot backups by using write-ahead log files
-from PostgreSQL and/or filesystem snapshots in order to take a
-consistent image of all the databases at a given time, or, if you can
-afford some down time, run offline backups. To run offline backups,
-disable the Landscape service and run a normal backup with
-`pg_dump`{.code} or `pg_dumpall`{.code}. Offline backup can take just a
-few minutes for databases at smaller sites, or about half an hour for a
-database with several thousand computers. Bear in mind that Landscape
-can be deployed using several servers, so when you are taking the
-offline backup route, remember to disable all the Landscape services on
-all server machines. See the [PostgreSQL documentation on backup and
-restore](http://www.postgresql.org/docs/9.1/interactive/backup.html) for
-detailed instructions.
-
-In addition to the Landscape databases, make sure you back up certain
-additional important files:
-
--   `/etc/landscape`{.filename}: configuration files and the LDS license
-
--   `/etc/default/landscape-server`{.filename}: file to configure which
-    services will start on this machine
-
--   `/var/lib/landscape/hash-id-databases`{.filename}: these files are
-    recreated by a weekly cron job, which can take several minutes to
-    run, so backing them up can save time
-
--   `/etc/apache2/sites-available/`{.filename}: the Landscape Apache
-    vhost configuration file, usually named after the fully qualified
-    domain name of the server
-
--   `/etc/ssl/certs/`{.filename}: the Landscape server X509 certificate
-
--   `/etc/ssl/private/`{.filename}: the Landscape server X509 key file
-
--   `/etc/ssl/certs/landscape_server_ca.crt`{.filename}: if in use, this
-    is the CA file for the internal CA used to issue the Landscape
-    server certificates
-
--   `/etc/postgresql/8.4/main/`{.filename}: PostgreSQL configuration
-    files - in particular, postgresql.conf for tuning and pg\_hba.conf
-    for access rules. These files may be in a separate host, dedicated
-    to the database. Use subdirectory 9.1 for PostgreSQL version 9.1,
-    etc.
-
--   `/var/log/landscape`{.filename}: all LDS log files
-
-Log files
----------
-
-Landscape generates several log files in
-`/var/log/landscape`{.filename}:
-
--   `update-alerts`{.filename}: output of that cron job. Used to
-    determine which computers are offline
-
--   `process-alerts`{.filename}: output of that cron job. Used to
-    trigger alerts and send out alert email messages
-
--   `process-profiles`{.filename}: output of that cron job. Used to
-    process upgrade profiles
-
--   `sync_lds_releases`{.filename}: output of that cron job. Used to
-    check for new LDS releases
-
--   `maintenance`{.filename}: output of that cron job. Removes old
-    monitoring data and performs other maintenance tasks
-
--   `update_security_db`{.filename}: output of that cron job. Checks for
-    new Ubuntu Security Notices
-
--   `maas-poller`{.filename}: output of that cron job. Used to check the
-    status of MAAS tasks
-
--   `package-retirement`{.filename}: output of that (optional) cron job.
-    Moves unreferenced packages to another table in the database to
-    speed up package queries
-
--   `appserver-N`{.filename}: output of the application server N, where
-    N (here and below) is a number that distinguishes between multiple
-    instances that may be running
-
--   `appserver_access-N`{.filename}: access log for application server
-    N; the application server handles the web-based user interface
-
--   `message_server-N`{.filename}: output of message server N; the
-    message server handles communication between the clients and the
-    server
-
--   `message_server_access-N`{.filename}: access log for message server
-    N
-
--   `pingserver-N`{.filename}: output of pingserver N; the pingserver
-    tracks client heartbeats to watch for unresponsive clients
-
--   `pingtracker-N`{.filename}: complementary log for pingserver N
-    detailing how the algorithm is working
-
--   `async-frontend-N`{.filename}: log for async-frontend server N; the
-    async front end delivers AJAX-style content to the web user
-    interface
-
--   `api-N`{.filename}: log for API server N; the API services handles
-    requests from landscape-api clients
-
--   `combo-loader-N`{.filename}: log for combo-loader server N, which is
-    responsible for delivering CSS and JavaScript
-
--   `job-handler-N`{.filename}: log for job-handler server N; the job
-    handler service controls individual back-end tasks on the server
-
--   `package-upload-N`{.filename}: output of package-upload server N,
-    which is used in repository management for upload pockets, which are
-    repositories that hold packages that are uploaded to them by
-    authorized users
-
-
-
-##Managing administrators
-
-
-Administrators are people who are authorized to manage computers using
-Landscape. You can manage administrators from the ADMINISTRATORS menu
-under your account.
-
-**Figure 4.1.**
-
-![image](./Chapter%A04.%A0Managing%20administrators_files/manageadmin1.png)
-
-\
-On this page, the upper part of the screen shows a list of existing
-administrators and their email addresses. You may create as many as
-1,000 administrators, or as few as one. If you're running Landscape
-Dedicated Server, the first user you create automatically become an
-administrator of your account. If you're using the hosted version of
-Landscape, Canonical sends you an administrator invitation when your
-account is created. After that, you must create additional
-administrators yourself.
-
-Inviting administrators
------------------------
-
-You make someone an administrator by sending that person an invitation
-via email. On the administrator management page, specify the person's
-name and email address, and the administration role you wish the person
-to have. The choices that appear in the drop-down list are the roles
-defined under the ROLES menu. See the discussion of roles below.
-
-When you have specified contact and role information, click on the
-Invite button to send an invitation. The message will go out from the
-email address you specified during Landscape setup.
-
-Users who receive an invitation will see an HTML link in the email
-message. Clicking on the link takes them to a page where they are asked
-to log in to Landscape or create an Ubuntu Single Sign-on account. Once
-they do so, they gain the administrator privileges associated with the
-role to which they've been assigned.
-
-It's worth noting that an administrator invitation is like a blank check
-- the first person who clicks on the link and submits information can
-become an administrator, even if it's not the person with the name and
-email address to which you sent the invitation. Therefore, take care to
-keep track of the status of administrator invitations.
-
-Disabling administrators
-------------------------
-
-To disable one or more administrators, tick the check boxes next to
-their names, then click on the Disable button. The adminstrator is
-permanently disabled and will no longer show up in Landscape. Though
-this operation cannot be reversed, you can send another invitation to
-the same email address.
-
-Roles
------
-
-A role is a set of permissions that determine what operations an
-administrator can perform. When you define a role, you also specify a
-set of one or more access groups to which the role applies.
-
-Available permissions:
-
--   View computers
-
--   Manage computer
-
--   Add computers to an access group
-
--   Remove computers from an access group
-
--   Manage pending computers (In the hosted version of Landscape,
-    pending computers are clients that have been set up with the
-    landscape-config tool but have not yet been accepted or rejected by
-    an administrator. Landscape Dedicated Server never needs to have
-    pending computers once it is set up and has an account password
-    assigned.)
-
--   View scripts
-
--   Manage scripts
-
--   View upgrade profiles
-
--   Manage upgrade profiles
-
--   View package profiles
-
--   Manage package profiles
-
-By specifying different permission levels and different access groups to
-which they apply, you can create roles and associate them with
-administrators to get a very granular level of control over sets of
-computers.
-
-
-
-
-##Access groups
-
-