59a483f8bd
Introduce the concept of "base services" (external services that OpenStack components can assume will be present in any OpenStack installation) and list current base services. This is intended to reflect the current situation. Changes to the list should be proposed as subsequent patches. You can find a more detailed analysis and rationale for this change in the Architecture WG analysis: http://git.openstack.org/cgit/openstack/arch-wg/tree/active/base-services.rst Change-Id: I77ffc000d895c3d8eb27b3b821c6c63f9dd2f675
2.0 KiB
Base services
Definition
Base services are services that OpenStack components can assume will be present in any OpenStack deployment. OpenStack components may therefore leverage advanced features exposed by those base services without fear of increasing the overall operational complexity for OpenStack deployers.
Current list of base services
- An oslo.db-compatible database
-
OpenStack components store data in a database, using oslo.db as an indirection layer. While most OpenStack deployments use MySQL, other databases are supported.
- An oslo.messaging-compatible message queue
-
Some inter-process and inter-service communication in OpenStack components is accomplished using message queues, through oslo.messaging as an indirection layer. While most OpenStack deployments use RabbitMQ, other message queues are supported.
- Keystone
-
Keystone handles AuthN/AuthZ for OpenStack components. Deployments can assume that Keystone will be present to perform that role.
Process for addition or removal
Leveraging features from a base service (rather than working around limitations or badly reinventing the wheel) is key to reaching acceptable levels of stability, performance and scaling. However, since they will likely have to be deployed in most OpenStack deployments, base services increase the operational complexity of running OpenStack. It is therefore very important to balance those two sides and conservatively consider proposed additions to the base services list, especially when those additions introduce a whole new class of operational challenges.
Once services start to make use of advanced features in a base service, it is difficult to remove it from the list and make it a specific dependency instead. Removals from the base service list should therefore be a rare and carefully considered event.
Proposed modifications to this document require a formal vote from the Technical Committee membership.