From 2b8aaaed53e3d9ca4a97d5923c135ab171144130 Mon Sep 17 00:00:00 2001 From: Shilla Saebi Date: Fri, 28 Feb 2014 17:14:33 -0500 Subject: [PATCH] cleanup module001-ch010-vm-provisioning-indepth Quantum changed to Neutron added plural receives changed authenticate to plural added the before request added and before authenticates added the before appropriate added the before nova-database return to plural added the before glance-api changed upload to plural and added the changed to "so that the" vs "such the" changed get to gets plural added the before instance added the before hypervisor driver capitalized api changed in-depth to In Depth Add markup Rework list so that step numbers match the graphic. Co-Authored-By: Andreas Jaeger Change-Id: I0e966c18f8783cbd04da813175da1e60d9753b2b --- .../bk001-ch005-associate-compute-node.xml | 2 +- ...odule001-ch010-vm-provisioning-indepth.xml | 267 ++++++++++++------ 2 files changed, 182 insertions(+), 87 deletions(-) diff --git a/doc/training-guides/bk001-ch005-associate-compute-node.xml b/doc/training-guides/bk001-ch005-associate-compute-node.xml index 5c763b1b9f..6214928b99 100644 --- a/doc/training-guides/bk001-ch005-associate-compute-node.xml +++ b/doc/training-guides/bk001-ch005-associate-compute-node.xml @@ -18,7 +18,7 @@
- VM Provisioning Indepth + VM provisioning in-depth Remote content not availableimage sourcehttps://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing diff --git a/doc/training-guides/module001-ch010-vm-provisioning-indepth.xml b/doc/training-guides/module001-ch010-vm-provisioning-indepth.xml index f4a520aad2..f954ad7186 100644 --- a/doc/training-guides/module001-ch010-vm-provisioning-indepth.xml +++ b/doc/training-guides/module001-ch010-vm-provisioning-indepth.xml @@ -4,115 +4,210 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="module001-ch010-vm-provisioning-indepth"> - VM Provisioning Indepth - More Content To be Added ... - The request flow for provisioning an Instance goes like - this: + VM provisioning in-depth + + + The request flow for provisioning an instance goes like + this: + + - Dashboard or CLI gets the user credentials authenticates - with Keystone via REST api. - - - Keystone authenticate the credentials and generate & send - back auth-token which will be used for sending request to other - Components through REST-call. - - - Dashboard or CLI convert the new instance request - specified in ‘launch instance’ or ‘nova-boot’ form to REST - API request and send it to nova-api. + + The dashboard or CLI gets the user credentials and authenticates + with the Identity Service via REST API. + + + The Identity Service authenticates the user with the user + credentials, and then generates and sends back an auth-token + which will be used for sending the request to other components + through REST-call. + - nova-api receive the request and sends the request for - validation auth-token and access permission to - keystone. - - - Keystone validates the token and sends updated auth headers - with roles and permissions. - - - nova-api interacts with nova-database. - - - Creates initial db entry for new instance. - - - nova-api sends the rpc.call request to nova-scheduler - excepting to get updated instance entry with host ID - specified. + + + The dashboard or CLI converts the new instance request + specified in launch instance or + nova-boot form to a REST API request and + sends it to nova-api. + - nova-scheduler picks the request from the queue. + + + nova-api receives the + request and sends a request to the Identity Service for + validation of the auth-token and access permission. + + + The Identity Service validates the token and sends updated + authentication headers with roles and permissions. + - nova-scheduler interacts with nova-database to find an - appropriate host via filtering and weighing. - - - Returns the updated instance entry with appropriate host ID - after filtering and weighing. - nova-scheduler sends the rpc.cast request to nova-compute for - ‘launching instance’ on appropriate host . - - - nova-compute picks the request from the queue. + + + nova-api checks for + conflicts with nova-database. + + + nova-api creates + initial database entry for a new instance. + - nova-compute send the rpc.call request to nova-conductor - to fetch the instance information such as host ID and flavor( - Ram , CPU ,Disk). + + + nova-api sends the + rpc.call request to nova-scheduler expecting to get + updated instance entry with host ID specified. + - nova-conductor picks the request from the queue. + + + nova-scheduler picks + up the request from the queue. + - nova-conductor interacts with nova-database. - - - Return the instance information. - nova-compute picks the instance information from the - queue. - - - nova-compute does the REST call by passing auth-token to - glance-api to get the Image URI by Image ID from glance and - upload image from image storage. + + + nova-scheduler + interacts with nova-database to find an + appropriate host via filtering and weighing. + + + nova-scheduler + returns the updated instance entry with the appropriate host + ID after filtering and weighing. + + + nova-scheduler sends + the rpc.cast request to nova-compute for launching an + instance on the appropriate host. + - glance-api validates the auth-token with keystone. - - - nova-compute get the image metadata. - nova-compute does the REST-call by passing auth-token to - Network API to allocate and configure the network such that - instance gets the IP address. - - - quantum-server validates the auth-token with - keystone. - - - nova-compute get the network info. - - - nova-compute does the REST call by passing auth-token to - Volume API to attach volumes to instance. + + + nova-compute picks up + the request from the queue. + - cinder-api validates the auth-token with keystone. + + + nova-compute sends the + rpc.call request to nova-conductor to fetch the + instance information such as host ID and flavor (RAM, CPU, + Disk). + - - nova-compute gets the block storage info. - - nova-compute generates data for hypervisor driver and - executes request on Hypervisor( via libvirt or api). + + + nova-conductor picks + up the request from the queue. + + + + + + nova-conductor + interacts with nova-database. + + + nova-conductor + returns the instance information. + + + nova-compute picks up the + instance information from the queue. + + + + + + nova-compute performs + the REST call by passing the auth-token to glance-api. Then, nova-compute uses the Image ID to + retrieve the Image URI from the Image Service, and loads the + image from the image storage. + + + + + + glance-api validates + the auth-token with keystone. + + + nova-compute gets the + image metadata. + + + + + + nova-compute performs + the REST-call by passing the auth-token to Network API to + allocate and configure the network so that the instance gets + the IP address. + + + + + + neutron-server + validates the auth-token with keystone. + + + nova-compute + retrieves the network info. + + + + + + nova-compute performs + the REST call by passing the auth-token to Volume API to attach + volumes to the instance. + + + + + + cinder-api validates + the auth-token with keystone. + + + nova-compute retrieves the + block storage info. + + + + + nova-compute + generates data for the hypervisor driver and executes the + request on the hypervisor (via libvirt or API). +
- Nova VM Provisioning + Nova VM provisioning