keystone，glance，nova結構都非常相似，使用wsgi協議,webob,paste,routes幾個框架，像我這樣以前Python沒接觸過的人可能也沒接觸過這些東西，先可以大致瞭解下這幾個框架，再來看原始碼就大致知道怎麼回事了。

先來說下keystone過程，下面是剛學習的時候記錄的，直接貼過來，可能存在錯誤，有問題請指出，謝謝。

啟動keystone服務時，需要查詢keystone.conf配置檔案並解析，通過keystone.conf配置的logging.conf解析logging日誌配置。

deploy.appconfig會解析paste.deploy配置中 main section的部分
create_server中deploy.loadapp
一開始與appconfig一樣，load app context。之後通過create方法解析paste配置的組成部分，並執行相關初始化。
use = egg:Paste#urlmap先得到解析執行，進入paste.urlmap#urlmap_factory，將先前loadContext得到的config map作為引數傳入。
這裡urlmap將會通過配置的uri和app對應起來，例如如果是composite:admin中的/2.0路徑，將會繼續通過查詢每一個section pre找到pipeline中有一個pipeline:admin_api。
然後查詢pipeline中最後一個應用的配置放入context.app_context，這裡是admin_service。
Admin_service的協議是paste.app_factory，執行的方法是keystone.service:admin_app_factory。
再同樣的方法查詢所有filter放入context.filter_contexts.然後用這個pipeline context呼叫create方法，pipeline中則是先create app context再依次create filter context。
（從這裡將從deploy模組回到keystone模組）Create app context執行admin_app_factory。
解析目錄模版：
Catalog.RegionOne.identity.publicURL
Region=RegionOne
Service=identity
Key=publicURL
組合成json格式串
{‘RegionOne’:{‘identity’:{‘publicuRL’:’http://localhost:${public_port}s/v2.0’}}}
最終將整個目錄模版解析成json格式的字典物件。
解析完成後得到一個帶有adminURL目錄資訊的version_controller，
之後向routes.mapper新增路由資訊，最終將構建完成的router返回給urlmap，完成請求路徑與路由路徑的一一對應。
路由物件儲存了請求路徑資訊，controller資訊，action資訊。
至此,Keystone-all執行完成，啟動了兩個server等待請求，一個是admin_port等待，一個是public_port等待。
請求到達服務時，將會按照paste配置執行filters，然後根據路由表配置進入模組方法執行。

上面的介紹實際主要是講paste和routes的過程，keystone利用這些框架，提供REST API，降低耦合，可以為各個模組提供使用者認證功能。
下面簡單介紹glance專案。
1.registry提供對DB操作的http服務，glance api通過對registry的http請求操作儲存在DB中的映象元資料，
雖然registry api可訪問，一般使用者不直接操作registry api

2.glance-api和glance-registry啟動服務後，分別根據應用名和專案名查詢paste配置檔案，並部署路由資訊
將映象元資料放入HTTP請求頭，並將映象檔案作為內容請求glance-api地址。 
glance-api接收請求，解析以x-image-meta和x-image-meta-property-開頭的請求頭資訊作為映象元資料， 
之後使用registry client請求registry服務，在DB中儲存映象元資料，並獲取ID值作為映象檔案儲存的檔名， 
檔案儲存或者以其他方式儲存完映象檔案後，再次請求registry服務更新映象狀態等元資料資訊。