- Preparing for the Certified OpenStack Administrator Exam
- Matt Dorn
- 329字
- 2025-02-22 13:07:19
OpenStack API communication
While the OpenStack service daemons rely on AMQP for communication among daemons within their specific service, the APIs are used both by OpenStack users wishing to create virtual resources and for service-to-service communication.

Envision a user sending a request to nova-api to boot an instance. In order to boot that server, quite a few internal API calls would need to take place. Let's look at an example sequence of API calls that would take place when booting a virtual machine instance.
An OpenStack user would first send a POST API call to the nova-api daemon with details about what sort of virtual machine they'd like. That message would get put on the AMQP message bus and consumed by the nova-scheduler daemon. The nova-scheduler daemon would then choose the best fit for the virtual machine using its scheduling algorithm. The nova-compute daemon residing on the compute node consumes this message. Before the server can be boot, the following must occur (see Figure 1.8):
- (1): The nova-compute daemon sends an API request to Keystone to retrieve a scoped token.
- (2): nova-compute gets back a 200 HTTP response along with a scoped token. Now nova-compute has a scoped token and can freely communicate with other OpenStack services.
- (3): nova-compute now sends a request to neutron-server to verify whether the specified virtual network on which to boot the instance is available.
- (4): nova-compute receives a response that the network is available and capable of attaching to the instance.
- (5): nova-compute must then send an API call to glance-api to retrieve the operating system image.
- (6): The glance-api responds back with the image that will reside on the compute node.
Now our instance will be booted! That was a lot of work!