Show complete workflow when provisioning an instance

[Anne Gentle]

I'd like to document an end-to-end flow of provisioning an instance on OpenStack Havana. I think this kind a sequence diagram helps to understand how OpenStack works and how many components has to co-operate to get a VM created.
Copy/paste the text below into https://www.websequencediagrams.com/ to see it

title Provision Instance

Client->+Keystone: Authentication Request
Keystone->+LDAP: authn
LDAP-->-Keystone:
Keystone->+Token Store:Save token
Token Store-->-Keystone:
Keystone-->-Client: Auth token

Client->+Nova-api: launch instance

Nova-api->DB: Create initial entry for instance
Nova-api->MQ: [rpc.cast] to request new instance
Nova-api->-Client:Instance request complete

Nova-scheduler->MQ: Subcribe new instance request
Nova-scheduler->DB: read filtering and weighing info
Nova-scheduler->DB: Read cluster state
Nova-scheduler->DB: Save instance state
Nova-scheduler->MQ: rpc.cast to launch instance

Nova-compute->MQ: Subcribe new instance request
Nova-compute->MQ: rpc.call to Nova-conductor to fetch the instance info
Nova-conductor->MQ: Subcribe new instance request
Nova-conductor->DB: Read instance state
Nova-conductor->MQ: Publish new instance state

Nova-compute->MQ: Subcribe new instance request

Nova-compute->+Glance-api: REST get Image URI by Image ID from glance
Glance-api->-Nova-compute: Return image URI

Nova-compute->+ceph_mon: get cluster map
ceph_mon->-Nova-compute: return map

Nova-compute->+ceph_rgw: [REST] request object
ceph_rgw->ceph_osd: [socket] get object
ceph_rgw->-Nova-compute: return object

Nova-compute->+Neutron-server: allocate and configure the network for instance
Neutron-server->MQ: Request IP
Neutron-server->MQ: Request L2 config

Neutron-DHCP-agent->MQ: read Request IP
Neutron-DHCP-agent->dnsmasq: allocate IP
dnsmasq->Neutron-DHCP-agent: reply
Neutron-DHCP-agent->MQ: reply IP

Neutron-server->MQ:read IP
Neutron-L2-agent->MQ: read Request L2 config
Neutron-L2-agent->libvirt: config L2
Neutron-L2-agent->MQ: reply L2 config
Neutron-server->DB: save instance network state
Neutron-server->-Nova-compute: Pass network info

Nova-compute->Cinder-api: [REST] get volume data
Cinder-api->+Keystone: Validate token & permissions
Keystone-->-Cinder-api: updated auth headers with roles and acl
Cinder-api->Nova-compute: return volume info

Nova-compute->libvirt: Start VM
Nova-compute->libvirt: Port_update

Nova-compute->MQ: rpc.call to Nova-conductor to fetch the instance info
Nova-conductor->MQ: Subcribe new instance request
Nova-conductor->MQ: Publish new instance state

Nova-compute->libvirt: pass volume info
libvirt->+ceph_mon: get cluster map
ceph_mon->-libvirt: return map
libvirt->ceph_osd: mount volume

VM-instance->+neutron_metadata_proxy: http rest 169.254.169.254
neutron_metadata_proxy->nova-api-metadata: http rest add uuid into X-headers
nova-api-metadata->neutron_metadata_proxy:
neutron_metadata_proxy->-VM-instance: return metadata

Client->+Nova-api: Poll instance state
Nova-api->+DB: Read instance state
DB->-Nova-api: Return state
Nova-api->-Client: Return instance state

[Anne Gentle (annegentle)]

I think this diagram makes sense in the Ops Guide perhaps or the User Guide to assist with troubleshooting.

[Anne Gentle (annegentle)]

Probably need to take the ceph reference out. Ari, do you know if cinder can be substituted there?

[Ari Flink (flinkster)]

Anne, we can take Ceph specifics out and replace it with cinder.

[Badri (badri-natarajan)]

Hello folks -

Would it be possible for someone to tell if the provisioning sequence mentioned above has changed from the Havana to the Icehouse/Juno releases ? Is it mostly still the same in the later releases as well?

Thanks.

[Anne Gentle (annegentle)]

This came in through email to me, asking for help with ensuring the workflow is accurate. So I think to work on this bug you'll have to go through the provisioning steps in the nova code itself, sorry. I don't know of another way to ensure the accuracy in a release. there is a post here: https://software.intel.com/en-us/articles/physical-server-provisioning-with-openstack that may help you get started.

[Anne Gentle (annegentle)]

Also came through in email.

-----
What does the following exchange stand for ?

##############
Nova-compute->+ceph_mon: get cluster map
ceph_mon->-Nova-compute: return map

Nova-compute->+ceph_rgw: [REST] request object
ceph_rgw->ceph_osd: [socket] get object
ceph_rgw->-Nova-compute: return object
##############

https://www.websequencediagrams.com/ is a choice though. Actually, we
can't see anything without paying 10$-15$. Ugh.

--------------------

[Romil Gupta (romilg)]

Probably, you could refer this. it's quite old but request flow is correct:

http://ilearnstack.com/2013/04/26/request-flow-for-provisioning-instance-in-openstack/
https://ilearnstack.files.wordpress.com/2013/04/request-flow1.png

[Masaki Furuta (masaki-furuta)]

Hi,

I've converted syntax for http://plantuml.com/ , please check if it works for you.

Client->Keystone: Authentication Request
Activate Keystone
Keystone->LDAP: authn
Activate LDAP
Keystone<--LDAP:
Deactivate LDAP
Keystone->"Token Store": Save token
Activate "Token Store"
Keystone<--"Token Store"
Deactivate "Token Store"
Keystone-->Client: Auth token
Deactivate Keystone

Client->"Nova-api": launch instance
Activate "Nova-api"
"Nova-api"->DB: Create initial entry for instance
"Nova-api"->MQ: [rpc.cast] to request new instance
"Nova-api"->Client:Instance request complete
Deactivate "Nova-api"

"Nova-Scheduler"->MQ: Subcribe new instance request
"Nova-Scheduler"->DB: read filtering and weighing info
"Nova-Scheduler"->DB: Read cluster state
"Nova-Scheduler"->DB: Save instance state
"Nova-Scheduler"->MQ: rpc.cast to launch instance

"Nova-compute"->MQ: Subcribe new instance request
"Nova-compute"->MQ: rpc.call to Nova-conductor to fetch the instance info
"Nova-conductor"->MQ: Subcribe new instance request
"Nova-conductor"->DB: Read instance state
"Nova-conductor"->MQ: Publish new instance state

"Nova-compute"->MQ: Subcribe new instance request
"Nova-compute"->"Glance-api": REST get Image URI by Image ID from glance
Activate "Glance-api"
"Glance-api"->"Nova-compute": Return image URI
Deactivate "Glance-api"

"Nova-compute"->ceph_mon: get cluster map
Activate "ceph_mon"
ceph_mon->"Nova-compute": return map
Deactivate "ceph_mon"

"Nova-compute"->ceph_rgw: [REST] request object
Activate "ceph_rgw"
ceph_rgw->ceph_osd: [socket] get object
ceph_rgw->"Nova-compute": return object
Deactivate "ceph_rgw"

"Nova-compute"->"Neutron-server": allocate and configure the network for instance
Activate "Neutron-server"
"Neutron-server"->MQ: Request IP
"Neutron-server"->MQ: Request L2 config

"Neutron-DHCP-agent"->MQ: read Request IP
"Neutron-DHCP-agent"->dnsmasq: allocate IP
dnsmasq->"Neutron-DHCP-agent": reply
"Neutron-DHCP-agent"->MQ: reply IP

"Neutron-server"->MQ:read IP
"Neutron-L2-agent"->MQ: read Request L2 config
"Neutron-L2-agent"->libvirt: config L2
"Neutron-L2-agent"->MQ: reply L2 config
"Neutron-server"->DB: save instance network state
"Neutron-server"->"Nova-compute": Pass network info
Deactivate "Neutron-server"

"Nova-compute"->"Cinder-api": [REST] get volume data
"Cinder-api"->Keystone: Validate token & permissions
Activate "Keystone"
"Cinder-api"<--Keystone: updated auth headers with roles and acl
Deactivate "Keystone"
"Cinder-api"->"Nova-compute": return volume info

"Nova-compute"->libvirt: Start VM
"Nova-compute"->libvirt: Port_update

"Nova-compute"->MQ: rpc.call to Nova-conductor to fetch the instance info
"Nova-conductor"->MQ: Subcribe new instance request
"Nova-conductor"->MQ: Publish new instance state

"Nova-compute"->libvirt: pass volume info
libvirt->ceph_mon: get cluster map
Activate "ceph_mon"
ceph_mon->libvirt: return map
Deactivate "ceph_mon"
libvirt->ceph_osd: mount volume

"VM-instance"->neutron_metadata_proxy: http rest 169.254.169.254
Activate neutron_metadata_proxy
neutron_metadata_proxy->"nova-api-metadata": http rest add uuid into X-headers
"nova-api-metadata"->neutron_metadata_proxy:
neutron_metadata_proxy->"VM-instanc...

[Basil Baby (basilbaby)]

Trying to understand it better, what is the "Nova-scheduler->DB: Read cluster state" ?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/351504

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/351504
Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=0703b973f91931e7d4ca7f2b88a57a6378bc54a3
Submitter: Jenkins
Branch: master

commit 0703b973f91931e7d4ca7f2b88a57a6378bc54a3
Author: daz <email address hidden>
Date: Fri Aug 5 16:19:22 2016 +1000

    [ops-guide] provision an instance

    Add sequence diagram and description of the end-to-end flow
    of provisioning an instance on OpenStack.

    Change-Id: I56c09a219eb05e3fb421f16fd009437a4097a665
    Closes-bug: #1359722

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/openstack-manuals 15.0.0 release.