Table Of Contents

Previous topic

The Glance Image Cache

Next topic

Getting Involved

This Page

Glance Architecture

Glance is designed to be as adaptable as possible for various back-end storage and registry database solutions. There is a main Glance API server (the glance-api program) that serves as the communications hub between various client programs, the registry of image metadata, and the storage systems that actually contain the virtual machine image data.

From a birdseye perspective, one can visualize the Glance architectural model like so:

digraph birdseye {
  node [fontsize=10 fontname="Monospace"]
  a [label="Client A"]
  b [label="Client B"]
  c [label="Client C"]
  d [label="Glance API Server"]
  e [label="Registry Server"]
  f [label="Store Adapter"]
  g [label="S3 Store"]
  h [label="Swift Store"]
  i [label="Filesystem Store"]
  j [label="HTTP Store"]
  a -> d [dir=both]
  b -> d [dir=both]
  c -> d [dir=both]
  d -> e [dir=both]
  d -> f [dir=both]
  f -> g [dir=both]
  f -> h [dir=both]
  f -> i [dir=both]
  f -> j [dir=both]

}

What is a Registry Server?

A registry server is any service that publishes image metadata that conforms to the Glance Registry REST-ful API. Glance comes with a reference implementation of a registry server called glance-registry, but this is only a reference implementation that uses a SQL database for its metdata storage.

What is a Store?

A store is a Python class that inherits from glance.store.Backend and conforms to that class’ API for reading, writing, and deleting virtual machine image data.

Glance currently ships with stores for S3, Swift, RBD, a simple filesystem store, and a read-only HTTP(S) store.

Implementors are encouraged to create stores for other backends, including other distributed storage systems like Sheepdog.