將邏輯架構映射到概念架構中，如下圖所示，可以看見我們還缺少什么：

這種覆蓋方式并不是唯一的，這里的只是作者的理解。通過覆蓋OpenStack Compute 邏輯組件，Glance和Dashboard，來表示功能范圍。對于每一個覆蓋，都有相應的提供該功能的邏輯組件的名稱。

• 在這種覆蓋范圍中，最大的差距是logging和billing。此刻，OpenStack Compute沒有能協調logging事件、記錄日志以及創建/呈現bills的Billing組件。真正的焦點是logging和Billing的整合。這能通過以下方式來補救。比如代碼擴充，商業產品或者服務或者自定義日志解析的整合。
• Identity也是未來可能要補充的一點。
• customer portal也是一個整合點。user dashboard(見運行的實例，啟動新的實例)沒有提供一個界面，來允許應用擁有者簽署服務，跟蹤它們的費用以及聲明有問題的票據(lodge trouble tickets)。而且，這很可能對我們設想的服務提供商來說是合適的。
• 理想的情況是，Admin API會復制我們能通過命令行接口做的所有功能。在帶有Admin API work的Diablo 發布中會更好。
• 云監控和操作將是服務提供商關注的重點。好操作方法的關鍵是好的工具。當前，OpenStack Compute 提供 nova-instancemonitor，它跟蹤計算結點使用情況。未來我們還需要三方工具來監控。
• Policy是極其重要的方面，但是會與供應商很相關。從quotas到QoS，到隱私控制都在其管轄內。當前圖上有部分覆蓋，但是這取決于供應商的復雜需求。為準確起見，OpenStack Compute 為實例，浮點IP地址以及元數據提供配額。
• 當前，OpenStack Compute內的Scheduling對于大的安裝來說是相當初步的。調度器是以插件的方式設計的，目前支持chance(隨機主機分配)，simple(最少負載)和zone(在一個可用區域里的隨機結點。)分布式的調度器和理解異構主機的調度器正在開發之中。
• 如你所見，OpenStack Compute為我們想象的服務提供商，提供了一個不錯的基礎，只要服務提供商愿意做一些整合。