Common use of Communication Model Clause in Contracts

Communication Model. OpenStack consists of several independent parts, named the OpenStack services. All services authenticate through a common identity service. Individual services interact with each other through public APIs, except where privileged administrator commands are necessary. Internally, OpenStack services are composed of several processes. All services have at least one API process, which listens for API requests, preprocesses them and passes them on to other parts of the service. With the exception of the identity service, the actual work is done by distinct processes. For communication between the processes of one service, an AMQP message broker is used. The service’s state is stored in a database. When deploying and configuring an OpenStack cloud, you can choose among several message broker and database solutions, such as RabbitMQ, MySQL, MariaDB, and SQLite. Users can access OpenStack via the web-based user interface implemented by Dashboard, via command-line clients and by issuing API requests through tools like browser plug-ins or curl. For applications, several SDKs are available. Ultimately, all these access methods issue REST API calls to the various OpenStack services. In Figure 2 an extract of the communication model is represented, with focus on the two most relevant services for the OPERA project, namely Compute and Orchestration. Figure 2 - OpenStack communication flow between Compute and Orchestration services.