OpenStack的發展已經迎來了全新階段，今后各家供應商將首先對其進行統一化互操作性測試，而后新版本才會正式與廣大用戶見面。以上表達來自OpenStack基金會首席運營官Mark Collier，他認為這種對互操作性的證明工作對于各家技術廠商而言極為重要。
隨著電信及銀行等新的企業成員加入進來，OpenStack基金會開始面臨更多對互操作性的需求壓力，這也直接促使其全力調整OpenStack項目自身以滿足此類要求。
OpenStack基金會指出，其下有30位組織機構成員至今從未對開源項目作出任何貢獻，但卻始終對該開源項目加以使用——這一數字較2014年20位有所增加。
為了保持OpenStack的代碼庫規模與自身聲譽，基金會方面決定在互操作性測試方面采取引導舉措。
就在本周三，十六家供應商借本屆巴塞羅那OpenStack峰會之機展示了一款測試LAMP應用，其能夠成功部署并運行在不同硬件以及OpenStack發行版之上。
而這款應用的根源，來自六個月之前由IBM公司在OpenStack的德克薩斯州奧斯汀峰會上發布的一項互操作性挑戰目標。
“我始終堅信這樣的事實，即著眼于未來，除非OpenStack能夠運行全部相關產品，否則各企業成員將選擇自行尋求可行的實現途徑，”Collier在本次大規?；ゲ僮餍哉故局蟮牟稍L中指出。
“當初我們規劃這項互操作性挑戰時，我們本以為只會有五、六家企業參與進來。然而但發布這項消息后，來電不斷且收件箱很快被塞滿——這意味著大家實際上都非常關注并希望自己的產品能夠被納入這份互操作性兼容名單。”
基金會常務董事Jonathan Bryce表示，這項挑戰展示出了互操作性的巨大價值。“我們希望鼓勵人們牢記互操作性的重要意義：相較于坐等六個月以被動期待特定功能被納入發行版當中，不如將其提交給上游社區并由我們執行相關工作，從而確保大家能夠切實獲得相關功能并保證其可與系統內的全部現有組件協同運作。”
要獲得OpenStack基金會的認可，各家成員企業必須證明自身的現有方案能夠與官方規范及API相兼容。本輪發布的新測試限定于特定應用，且主要面向工作負載。
這一測試應用屬于OpenStack旗下一支工程團隊的開發成果，該團隊主要在編排與容器管理領域圍繞Heat與Chief開展工作，并將Docker與網絡功能虛擬化項目作為工作負載; 最終以說明文檔及代碼的形式將其納入編排工具當中。OpenStack基金會計劃進一步加大這方面工作的推進力度。
Collier認為不必強制設定具體工作量。“我相信所有發布產品的企業都會在自己的產品化流程當中納入這一測試機制——它們會自覺設立互操作性標準并加以執行。我認為我們并不需要進行強制性要求。”
與此同時，OpenStack基金會還于今年8月批準了一項新的OpenStack規范，其將功能數量由125個增加至225個。
隨著更多內容被添加到基礎規范中來，成員們希望能夠盡量減少由不受支持功能所帶來的困擾與產品開發阻礙。
對于OpenStack項目來說，互操作性也因此成為一個愈發嚴重的難題。
所有開源項目的狂熱參與者都樂于發布fork，而新成員對于開源領域的經驗欠缺已經給OpenStack帶來巨大壓力——這意味著其迫切需要出臺一項新策略，用于解決此類問題。
曾有某位基金會成員構建起了自己的一套DNS管理系統，而未等待OpenStack方面的官方解決方案。OpenStack DNS管理已經于六個月前完成開發，并被納入Nova當中以供全部社區成員加以使用。這意味著此前開發的這套獨立DNS管理系統在耗費了大量資源之后，將無任何發展前景可言。
“這意味著其嚴重缺乏成本效益。效益非常短暫，而投入的時間與資金成本則相當高昂，”Collier表示。
Bryce認為，新的OpenStack參與各方可能會以紅帽Linux等操作系統的方式消費開源成果，但OpenStack則將成為其首個真正作出代碼貢獻的開源項目。
“第一波開源浪潮的勝利很像是從專有供應商處購買技術的消費模式，”Bryce解釋稱。“為了能夠讓開源成果進入企業，紅帽公司獨力前行并采取類似于微軟的產品銷售策略。”
“如今大家有了OpenNFV，且從傳統角度講并不直接參與知識產權開發工作的電信服務商，都已經加入到了項目構建的流程中來。”
“他們在看到源代碼時會說：‘如果我能實現這項功能，那么為什么不能實現另一項功能？’而這正是促進其學習的動力所在。”
京公網安備 11010502049343號