Puppet Openstack Mitaka Design Summit小結

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社區的積極參與。