The following paragraphs give some details on the main modules in the OpenStack components.
These details are not meant to be exhaustive; the objective is to describe the relevant aspects that administrators need to know to better understand how to design the deployment, and install and configure the whole platform.
Modules are organized according to the functional area they belong (i.e. the kind of functions they implement or deliver) and classified according to their type.
These are the types:
daemon: runs as a daemon and, on Linux platforms, is usually installed as a service;
script: a script run by an external module when some event happens (at the moment, it is used as a co-routine of dnsmasq for managing IP Addresses released to instances via DHCP protocol);
client: a client for accessing the Python bindings for a service
CLI: a Command Line Interpreter for submitting commands to OpenStack Compute for example
As you can imagine, the logical architecture is far more complicated than the conceptual architecture shown above. As with any service-oriented architecture, diagrams quickly become "messy" trying to illustrate all the possible combinations of service communications. The diagram below, illustrates the most common architecture of an OpenStack-based cloud. However, as OpenStack supports a wide variety of technologies, it does not represent the only architecture possible.
This picture is consistent with the conceptual architecture above in that:
End users can interact through a common web interface (Horizon) or directly to each service through their API
All services authenticate through a common source (facilitated through Keystone)
Individual services interact with each other through their public APIs (except where privileged administrator commands are necessary)
In the sections below, we'll delve into the architecture for each of the services.
