Jump to: navigation, search

Difference between revisions of "HeterogeneousTileraSupport"

Line 30: Line 30:
See [[HeterogeneousInstanceTypes]].
See [[HeterogeneousInstanceTypes]].
The goal is to allow openstack to launch virtual machines with a large number of cores and large amount of memory.  Our relatively small test machine has 256 cores and 512GB of main memory in a SMP single system image.  There are many user scenarios that involve subdividing this pretty expensive piece of monolithic hardware across multiple customers with different configuration requirements.  Even with a standard X86_64 virtual machine image taken from a stock openstack glance repository, an instance could be provisioned with 64 cores and 256GB of memory without modification.
== User stories ==
== User stories ==

Revision as of 16:42, 29 March 2011


This blueprint proposes to add support for the Tilera tiled-processor machines as an alternative machine type in OpenStack. This blueprint is dependent on the schema changes described in the HeterogeneousInstanceTypes blueprint and the scheduler in HeterogeneousArchitectureScheduler.

The target release for this is Diablo, however the USC-ISI team intends to have a stable test branch and deployment at Cactus release.

The USC-ISI team has a functional prototype here:

This blueprint is related to the HeterogeneousInstanceTypes blueprint here:

We are also drafting blueprints for other machine types:

An etherpad for discussion of this blueprint is available at http://etherpad.openstack.org/heterogeneoustilerasupport

Release Note

Nova has been extended to allow support for the SGI UV family of shared memory machines.


See HeterogeneousInstanceTypes.

User stories

She chooses a sh1.8xlarge with 128GB of memory and 64 cores.

euca-run-instances -t tp.8xlarge -k jackie -keypair emi-12345678


This blueprint is dependent on sh1.8xlarge being a selectable instance type and that the scheduler knows this large of an instance must get routed to a big shared memory machine. See HeterogeneousArchitectureScheduler.


We propose to add cpu_arch, cpu_info, xpu_arch, xpu_info, xpus, net_arch, net_info, and net_mbps as attributes to instance_types, instances, and compute_nodes tables. See HeterogeneousInsanceTypes. The tilera machine is unique in that it has a NxN mesh of processor cores. Currently there is no support for KVM or XEN virtualization, so we are doing a bare metal approach.

Schema Changes

See HeterogeneousInsanceTypes.

We're proposing the following default values added to the instance_types table.

    't64.8x8':  dict(memory_mb=16384, vcpus=1, local_gb=500,
   'tp64.8x8': dict(memory_mb=16384, vcpus=1, local_gb=500,
   'tgx.4x4':  dict(memory_mb=16384, vcpus=1, local_gb=500,
   'tgx.6x6':  dict(memory_mb=16384, vcpus=1, local_gb=500,
   'tgx.8x8':  dict(memory_mb=16384, vcpus=1, local_gb=500,
   'tgx.10x10':  dict(memory_mb=16384, vcpus=1, local_gb=500,


The USC-ISI team has a functional prototype: https://code.launchpad.net/~usc-isi/nova/hpc-trunk

UI Changes

The following will be available as new default instance types.

Tilera Tile Pro 64

  • API name: tp64.8x8
  • 16 GB RAM (16384 MB)
  • 64 (8x8) cores
  • 1 TB storage
    • Tilera TILEPro 64

(Only one Tilera instance type for now. When KVM support appears, we will add additional types to support partitioning into smaller instances)

Code Changes

  • db/sqlalchemy/migrate_repo/versions/013_add_architecture_to_instance_types.py
  - add default instance types for tilera


Very little needs to change in terms of the way deployments will use this if we set sane defaults like "x86_64" as assumed today.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

One of the challenges we have is that the flavorid field in the instance_types table isn't auto-increment. We've selected high numbers to avoid collisions, but the community should discuss how flavorid behaves and the best approach for adding future new instance types.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.