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]
}](_images/graphviz-510b4e8c588f1cd0405eac6b9fd6cdceea91932c.png)
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, 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 or Ceph.