转载：http://taget.github.io/lessons/2014/09/18/request-data-flow/，作者：Eli Qiao
摘要：分析openstack环境中boot一个vm详细的业务流程，以nova为核心实现的接口驱动过程，非常有学习价值。
Data flow of openstack request
This post will talk about the data flow of an openstack request, I will take boot an instance and shelve an instance as example.
Assume that you have setup an openstack environment already.
Let’s start from nova client, you can put –debug option to nova client then you will see the request url nova client sent.
Boot an instance
[tagett@stack-01 devstack]$ nova --debug boot t3 --flavor m1.nano --image 44c37b90-0ec3-460a-bdf2-bd8bb98c9fdf --nic net-id=b745b2c6-db16-40ab-8ad7-af6da0e5e699
…
REQ: curl -i 'http://cloudcontroller:5000/v2.0/tokens'
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/images/44c37b90-0ec3-460a-bdf2-bd8bb98c9fdf'
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/flavors/m1.nano'
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/servers' -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-novaclient" -H "X-Auth-Project-Id: admin" -H "X-Auth-Token: {SHA1}15d9e554b7456f1043732bb8df72d1521c5f6aa1" -d '{"server": {"name": "t3", "imageRef": "44c37b90-0ec3-460a-bdf2-bd8bb98c9fdf", "flavorRef": "42", "max_count": 1, "min_count": 1, "networks": [{"uuid": "b745b2c6-db16-40ab-8ad7-af6da0e5e699"}]}}'
…
The requests from nova client are:
1) Get token from keystone server with username and password, keystone will return the token, and also the tenant id.
2) Send another request with tenant id (d7beb7f28e0b4f41901215000339361d) and token to check if image existed.
3) Send another request with tenant id (d7beb7f28e0b4f41901215000339361d) and token to check if favors existed.
4) Request to create an instance, all request data are put in the request body, check –d section.
Nova client help you to make all requests together, the most important one is the 4), if you are sure about all resources, you can simply run 4) to create an instance.
The date flow will be follows:
Nova client -> nova-api -> nova-conductor->nova-scheduler->nova-compute
Each one is an service(a running process), they call each other through rpc server.
Let’s take a look at the service side code.
The nova-api service is an wigi server, you can find the code from:
nova /api/openstack/compute/servers.py
The handle function is
def create(self, req, body):
"""Creates a new server for a given user."""
…
(instances, resv_id) = self.compute_api.create(context,
After doing so many check, it finally calls the function of create() which defined in compute_api
The code locates at nova/compute/api.py
@hooks.add_hook("create_instance")
def create(self, context, instance_type,
...
return self._create_instance(
some validation and option are done in _create_instance function. Then calling
self.compute_task_api.build_instances(context,
compute_task_api is an rpc request to nova-conductor service.
Go to nova/conductor/manager.py, We will find the function
def build_instances(self, context, instances, image, filter_properties,
…
hosts = self.scheduler_rpcapi.select_destinations(context,
…
self.compute_rpcapi.build_and_run_instance(context,
It mainly does 2 things, send request to nova-scheduler to find a host which the newly created instances will run on, and send request to these hosts’ to run an instance.
Then we go to nova/compute/manager.py, which will receive the request from conductor , and it
def build_and_run_instance(self, context, instance, image, request_spec,
filter_properties, admin_password=None,
injected_files=None, requested_networks=None,
security_groups=None, block_device_mapping=None,
node=None, limits=None):
this function will call the really hypervisor driver to create instance. each service does its own job.
- nova-api: accept the url request and response to client
- nova-conductor: talk to db, improve the security of db access
- nova-scheduler: find an specify node though some require specification.
- nova-compute: do the really compute node related job.
not all of request will call all the services.
Shelve an instance
[tagett@stack-01 devstack]$ nova list
+--------------------------------------+-----------+-------------------+------------+-------------+-----------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-----------+-------------------+------------+-------------+-----------------------------------+
| 00be783d-bef5-46b1-bfdc-316618c76e92 | t2 | ACTIVE | - | Running | private=192.168.1.82 |
+--------------------------------------+-----------+-------------------+------------+-------------+-----------------------------------+
Then shelve an instance:
[tagett@stack-01 devstack]$ nova --debug shelve t2
REQ: curl -i 'http://cloudcontroller:5000/v2.0/tokens' …
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/servers'…
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/servers/r'…
…
REQ: curl -i 'http://cloudcontroller:8774/v2/d7beb7f28e0b4f41901215000339361d/servers/00be783d-bef5-46b1-bfdc-316618c76e92/action' -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-novaclient" -H "X-Auth-Project-Id: admin" -H "X-Auth-Token: {SHA1}0634ea0ef1c3994e1f496c5d8890d32610cf11e9" -d '{"shelve": null}'…
There are 4 requests you can see from above, you will see the full request url with request body and also you can find the response code body.
The requests are:
1) Get token from keystone server with username and password, keystone will return the token, and also the tenant id.
2) Send another request with tenant id (d7beb7f28e0b4f41901215000339361d) and token. You will get all instances the tenant created.
3) Another request is check if the instance you want to shelve (00be783d-bef5-46b1-bfdc-316618c76e92) exist.
4) Do shelve, you can see it is an post request with the body -d ‘{“shelve”: null}’
At last , nova api return an response as:
RESP: [202] CaseInsensitiveDict({'date': 'Thu, 18 Sep 2014 04:03:09 GMT', 'content-length': '0', 'content-type': 'text/html; charset=UTF-8', 'x-compute-request-id': 'req-4be7dc9a-21da-4050-9310-3ee58ca93569'}) RESP BODY: null
Server has accepted(202) your request and will do the shelve asynchronous.
This is what you can see from client side.
Then here’s the server side.
The basic service calling sequence is: Novaclient -> nova-api -> nova-conductor -> nova-compute
the api code of shelve is in nova/api/openstack/compute/contrib/shelve.py it is an extension of server(as you can see from the request of shelve) you can find the follow code:
nova/api/openstack/compute/contrib/shelve.py :
@wsgi.action('shelve')
def _shelve(self, req, id, body):
"""Move an instance into shelved mode."""
context = req.environ["nova.context"]
auth_shelve(context)
instance = self._get_instance(context, id)
try:
self.compute_api.shelve(context, instance)
except exception.InstanceIsLocked as e:
raise exc.HTTPConflict(explanation=e.format_message())
the api service will call nova compute api ‘s function shelve, the code located at nova/compute/api.py
if not self.is_volume_backed_instance(context, instance):
name = '%s-shelved' % instance['display_name']
image_meta = self._create_image(context, instance, name,
'snapshot')
image_id = image_meta['id']
self.compute_rpcapi.shelve_instance(context, instance=instance,
image_id=image_id)
else:
self.compute_rpcapi.shelve_offload_instance(context,
instance=instance)
then it make a rpc call though compute_rpcapi, the message will send to amqp server and it will received by compute manager, to let’s check the code in nova/compute/manager.py
so the data flow will be
