Information Services

Technical description

Technical description of the Grace Cloud service, providing information about the technology used and the suitability of the service for applications.

Orchestration & Infrastructure as Code

It is recommended that to get maximum value out of the cloud service that you leverage the API's through a configuration management tool of your choosing, e.g. Puppet/Chef/Ansible. 

Furthermore, OpenStack provides an Orchestration engine called Heat. This is an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code, e.g. Infrastructure as Code

Additionally we are looking at possibly providing additional tooling through Terraform, if this service would be of value to you please let us know.

Compute Regions

We have three distinct compute regions: one each at KB and AT and a "free" region. The regions currently present are nova-kb, nova-at and nova-free. To control your VMs placement you should define the relevant compute region.

The nova-free region is for a distinct compute cluster that facilitates the provision of time bounded free trial allocations to allow easy entry to the service. The free tier can be oversubscribed up to a significant factor and so this means that the performance of your instances may vary depending on usage from other Free Tier users.

The main compute regions have around 4.5TB of RAM, 450vCPUs & 50TB of storage.

Charged vs Free Regions

Each project will be allocated into the charged or free mode.

Free projects will be available to any user and will be time bounded.

Charged Projects rates for both Research Services & IS Enterprise Services OpenStack will be broadly inline with each other.


If you attempt to use a compute region that your project does not have rights to the instance will fail to launch with no suitable location found.


Each school/department can  be allocated a charged project. The members of this project should be denoted by some automatically managed Active Directory group, e.g. org hierarchy or similar.

Each school/department will be allocated a quota, and a provider network (see quota’s and provider networks sections for more detail).

Free projects will be spun up against individual University Usernames (UUNs).


We are providing the facility to create volumes. An OpenStack volume is a detachable block storage device. You can attach a volume to only one instance. You can migrate a volume with its data from one location to another in a manner that is transparent to users and workloads. You can migrate only detached volumes with no snapshots.


The following flavours for your Virtual Machines are available:

Flavour Memory size Disk allocation

Number of virtual CPUs

tiny 512 MiB 1 GiB 1 vCPU
small 2 GiB 20 GiB 1 vCPU
medium 4 GiB 40 GiB 2 vCPUs
large 8 GiB 80 GiB 4 vCPUs
xlarge 16 GiB 160 GiB 8 vCPUs

If your project is a charged project then the flavours will be prefixed with a "c." If your project is a free project then the flavours will be prefixed with a “f.”


When using the API - flavours are referenced with the American spelling “flavors”


All Virtual Machines are launched from images, we have provided a sample of some popular Operating Systems:

  • CentOS7 x86_64                        (CentOS-7-x86_64-Cloud-UoE)
  • Debian Jessie x86_64              (Debian-Jessie-x86_64-Cloud-(8.8.1))
  • RHEL7 x86_64                             (RHEL-7.3-x86_64-Cloud) ** RHN license required and not included
  • Ubuntu 14.04 LTS                      (ubuntu-14.04-server-amd64)
  • Ubuntu 16.04 LTS                      (Ubuntu-Server-16.04-VMDK-Paravirtual)
  • CirrOS 0.3.5                                 (cirros-0.3.5)


We are looking to provide a Windows Image, this is still in flight and at the time of writing this is not yet available.

Other images can be imported, our recommendation is to convert the relevant QCOW2 or RAW images and then import that image.

If you think the image might be of use to others you can mark it as public and other users can consume it.

Please note that where an Operating System requires a license, such as Windows or RedHat Enterprise you need to provide that license.


Each Project will be assigned a quota.

We have assigned the following defaults:

  • 0.5TB RAM
  • 1TB disk
  • 128x vCPUs
  • 128x Instances
  • 1000 Virtual IPs

Charges for quota's will be Documented in "Availability and entitlement".

Changes can be made to the above on request.

Free quota's will be more restrictive:

  • 1GB RAM
  • 20GB Disk
  • 2x vCPUs
  • 2x Instances
  • 2x Virtual IPs

Free projects will expire automatically after 60 days.

Provider Networks

 Provider Networks are the network ranges where your Virtual Machines will be spun up.

Currently each charged project will be allocated a /22 RFC 1918 IP space for your project. These networks provide L2 networking only, i.e. you cannot create your own networks, routers, and subnets. L3 networking requirements should be completed inside the guest virtual machines, this will be best done via your configuration management tool of choice.

There are resilient DHCP servers for each /22 network range.

Default firewall rules will be defined on the central ASA by each project owner.

All Provider Networks are based on RFC 1918 IP spaces and so access from outside EdLAN you will need to use the VPN.  

Object Store

An Object Store is being provided. This is based upon Swift. We do not provide a backup of objects stored in the object store.

SSH Keys

To log in to virtual machine instances you will need an SSH key pair, passwords are not used (although you're free to set one once you've logged in to the instance for the first time). You can upload your public keys into your project and re-use them, defining the relevant keypair at instance instantiation (tip: give your keypair a descriptive name so you can easily identify it).

The default username for each Operating System image is in the description field of the image.


The administrative components which make up the OpenStack Service are backed up. There is no provision of backup for ephemeral instances.

Console Access

Each virtual machine can be accessed directly via it's console, this is provided via the Horizon web interface. Click on your Instance and then "Console".