Puppet Openstack Design Summit小結
經過Puppet Openstack社群的不斷努力，Puppet Openstack社群目前提供的Official Modules已經成熟，直接被用於Mirantis Fuel，Redhat PackStack等主流的部署工具中。
因此從Juno版本開始，社群的重心逐漸地轉移到如何提供更全面的測試，如何抽取公共庫以及規範架構等等程式碼的優化工作上。
本次Puppet Openstack Work Session放在古色古香的Aoi會議室舉行，由於參會人員較多，地板上也坐滿了人。由於議題數量較多，每個議題的時間較長，破天荒地被拆分為三場，主要討論以下問題：
1. init類的重構
為了向後相容大量的廢棄配置選項以及支援不斷增長的新配置選項，當前的init.pp類越來越臃腫，這對於程式碼維護和理解帶來了困難。最終得出解決方法概括來說有以下點：
- 將所有配置選項根據型別拆分為子類
- init類使用include子類來實現呼叫
- 不破壞原有介面
- 定期清理用於向後相容的程式碼（就像清理草坪）
2. 增加管理定製化引數的方法
會議現場有人提出了每個專案為了支援新引數而在不停地更新module，需要有一種方法能夠在不改動module層的基礎上，通過在hiera層面來應對此挑戰，PTL提到了當前的module::config已經能夠很好支援此需求。這個重要feature最初是由UnitedStack貢獻的，目前puppet-murano外，其他二十多個module均已支援定製化引數。
圖為 PTL Emilien在談及module::config的程式碼
3.處理客戶端的warning級別輸出
由於在某些情況下，client端會輸出一些warning級別的日誌，然而puppet當前的解析輸出機制（不區分stdout/stderr）並不支援此類場景。已有新patch提交到了puppet-openstacklib公共庫專案，方法是通過正則匹配的方式來只過濾掉warning資訊，仍會捕獲error級別的輸出。但這個問題仍然治標不治本，由此引出了下個議題。
4.擴充套件性問題 Ruby庫 vs OSclient
每場 work session的時間是40分鐘，而大家在這個問題上爭論非常激烈，以至於連10分鐘的中場休息也沒有放過，這個話題足足討論了30分鐘。
簡單介紹該議題的上下文：當前puppet呼叫各服務的API介面獲取資源資訊是通過custom resource type和facter來獲取的，這些自定義的指令碼又是通過呼叫python-openstackclient的命令列介面來實現以上功能。
在最近的ML討論中，由Mirantis的Sergey發現puppet-neutron模組在某種情況下，在議題3中我們已經知道Puppet傻傻分不清楚標準和錯誤輸出，導致抓取了錯誤的輸出資訊，從而獲取了不正確的net id。
說實話，社群在這個問題上已經在ML和IRC上經過了多屆拉鋸戰般的討論：要不要自己造個輪子，寫個Ruby版本的SDK。
其實在OSclient之前，大家飽受使用各專案Client的痛苦（介面和輸出不統一），於是由原Puppetlabs公司的美女工程師Crinkle發起，（索要照片請私信）寫了一個Ruby SDK。但不久之後，OSClient橫空出世，這個專案就被雪藏了。但現在大家發現在ruby中使用osclient的命令列介面還是比較坑爹的，於是又懷念起純正血統的ruby SDK。
那麼既然決定要幹：大家又開始討論應該怎麼做，怎麼利用現有的專案資源，如何使用現有的公共庫等等各種問題（一言蔽之，怎麼偷懶）。最終的結論是這樣的：
It would be really really cool to have a ruby sdk for OS.
持反對意見者稍加潤色以表示他們的懷疑態度：
It would be really really cool to have a (good) ruby sdk for OS
5.增加健康檢測module
這是一個比較有意思的專案，例如我們希望能夠在Puppet將服務啟動或者重啟後，有一個機制可以確認API服務是正常執行的。比如手動使用一個簡單的curl命令，判斷web應用的狀態返回碼。因此，有些工程師在一些類中新增了監控檢測的程式碼來做這樣的事情。不過都是一些鬆散分散在各個專案中的程式碼，因此社群這次把健康檢測抽象成一個獨立的module，提供標準的class和define介面，方便程式碼複用和持續地優化。
6.在*_config resource type中新增處理棄用配置選項的功能
這個topic屬於一個新特性的討論，例如，在Kilo版本開始，rabbit_hosts引數從DEFAULT section中移動到了slo_messaging中去。因此，我們希望通過以下格式將neutron中關於rabbit_hosts的新舊引數都集中管理起來：
neutron_config { 'oslo_messaging/rabbit_hosts': old_key => 'DEFAULT/rabbit_hosts', value => $value}
由於屬於大家都喜聞樂見的特性，無人持異議，並且該議題的提出者clayton將如何實現的細節都寫到了etherpad上（應放在puppet-specs裡討論實現的細節）。PTL戲稱，你這是要讓大家在etherpad給你+1的節奏嘛？一時間會議室裡充滿了快活的空氣。
其他還有一些小的議題，例如PTL跪求更多的人蔘與到貢獻和審查程式碼的工作中來（因為現在參與人員龐大，core member不夠用了，每天都有審查不完的patch），還有當前puppet-ceph模組的進展和roadmap等等，這裡就不再展開介紹了
通過這幾屆的design summit來看，Puppet Openstack社群已經完成了從無到有，從有到好的階段，在完成了眾多基礎模組的開發以及公共庫模組的抽取工作之後，社群當前的目標是進一步完善每個模組，確保可以處理各種異常情況，為終端使用者或其他開發人員提供更好的部署服務。
UnitedStack Devops team在最近釋出的Liberty版本中對Puppet Openstack社群做出了積極貢獻，排名第四。在隨後的Mikata Release開發中，我們會繼續保持對Puppet Openstack社群的積極參與。