【51CTO.com快譯】一直以來OpenStack都只是用Python編寫的，別的語言不是沒用只是用到的很少，核心部分幾乎都是Python，現(xiàn)有人提議讓Go語言也用在API服務(wù)方面。

在新版本Newton出爐的周期中，技術(shù)評估委員會接到了一份把Go語言作為OpenStack官方開發(fā)語言的提議。隨后進(jìn)行了許多討論，這里不過多贅述過程，只是談?wù)剮c討論的結(jié)果。

決議是暫時拒絕讓Go作為官方開發(fā)語言，但表示未來可以接著討論，我覺得Go被拒絕可能有以下幾方面的原因：

1.技術(shù)委員會成員擔(dān)心增加新的語言會對社區(qū)造成的影響。會不會對社區(qū)帶來分裂，會不會形成一個孤島，會不會給新入門的人帶來額外的門檻？
2.技術(shù)委員會的一些成員認(rèn)為如今對社區(qū)中的一些方面缺乏信息，研究和工作。 Go代碼如何在整個社區(qū)中共享？ 認(rèn)證怎么做？ 消息層怎么弄？ 如何產(chǎn)出版本？ 如何維持分支的穩(wěn)定？
3.提議Go語言的團(tuán)隊除了自己的項目以外根本就沒做過跨項目的任務(wù)，這不由得引起了懷疑，使得許多技術(shù)委員會的質(zhì)疑是否能夠順利完成。

接受一門新的語言需要哪些條件呢？

我先聲明，我所說的不代表技術(shù)委員會而僅代表我個人意見，從而方便交流，好會讓整個社區(qū)的人發(fā)表意見，無論是同意或者反對我的想法。

討論期間我最關(guān)心的是***部分，主要是因為我覺得向“Big Tent”的遷移還沒完成。我也不知道怎么才會讓我覺得這遷移已經(jīng)完成了，我能肯定的是我們在解決大的變化發(fā)生前需要解決的問題。

言歸正傳，我越來越喜歡給許多東西設(shè)定期望，尤其是一些能帶來改變的請求。把預(yù)期列出來之后，就能讓相關(guān)的人了解到他們正在向哪一個方向行進(jìn)，并且找到改變可能會面臨的問題。

我對第二個問題遠(yuǎn)沒有***個問題那么擔(dān)心。它會對參與討論這一變化的團(tuán)隊表現(xiàn)出很強(qiáng)的承諾，因為這涉及到未來對社區(qū)所有成員使用和參考的基礎(chǔ)知識庫。我以為第二部分的工作可能有些超綱，但并不是這樣。通過研究怎么共享代碼，怎么測試代碼，怎么輸出代碼，怎么做認(rèn)證庫等，我們在設(shè)定未來實際工作中需要用到的基礎(chǔ)的東西。

無論如何，我上面提到的“基礎(chǔ)的東西”是什么呢？我將在下面不太詳盡的列表中簡單談一下：

為新語言定義分享代碼和庫的方式

Oslo Team負(fù)責(zé)維護(hù)整個OpenStack社區(qū)需要經(jīng)常用到的庫。這些庫包括消息庫（oslo.messaging）,i18n庫（oslo.i18n），數(shù)據(jù)庫層庫（oslo.db）等關(guān)鍵庫。

這些庫本身并不能讓Oslo組的人忙起來，它們是為了收集以前在社區(qū)中存在于許多項目中的重復(fù)性的公共代碼。這個代碼現(xiàn)在由Oslo移除，穩(wěn)定和發(fā)布。

我覺得作為一個社區(qū)，這是無可避免的。一旦越來越多的項目使用相同的語言就會出現(xiàn)共享代碼的需求。 因此，我覺得我們需要更好地定義一個編程語言的代碼怎么在社區(qū)共享，這個挺重要的，哪怕是在編程語言被接受之前就很重要。

我覺得提前做一些事情不意味著將來沒事可做，我們都知道會有許多為預(yù)料到的事情和發(fā)生變化的事情，我覺得這些工作能涉及到大部分初始化的工作。

關(guān)于OpenStack基本服務(wù)的基本庫

這可能看起來像一個相當(dāng)高的目標(biāo)。雖然想搞清楚代碼如何共享是一個很困難的需求，但我認(rèn)為這離OpenStack服務(wù)的***要求還差很遠(yuǎn)。

集成在生態(tài)系統(tǒng)中的OpenStack服務(wù)至少需要以下任意一個庫：

•keystoneauth / keystone-client
•oslo.config
•oslo.db
•oslo.messaging

如果在使用數(shù)據(jù)庫或者消息隊列抽象庫的時候沒有任何消耗的話，很可能提供的抽象層是錯的，從而導(dǎo)致糟糕的API。從另一個方面說，認(rèn)證層是幾乎所有OpenStack服務(wù)都會用到的部分，應(yīng)該可以很方便使用才對，但這不是說這件事本身很簡單。

通過處理這些庫中的任何一個，都可以進(jìn)行CI（自動測試系統(tǒng)）作業(yè)，通過這些作業(yè)來確保新項目的基礎(chǔ)設(shè)置是正確。

定義可交付項如何分布

OpenStack的發(fā)布過程幾乎完全是自動化的，發(fā)布過程中涉及到的所有可交付項都是由社區(qū)自動產(chǎn)出并由發(fā)布團(tuán)隊來管理的。***，將每個交付項生成壓縮包。

目前使用Python編程語言（以及其他幾門編程語言）的時候 ，這些壓縮包因為只包含這些源代碼所以還很簡單。對于像Go這樣的編譯型語言，我們就得考慮壓縮包里要壓縮什么了，壓縮編譯過的二進(jìn)制代碼嗎？是不是應(yīng)該加入源代碼呢？如果要包含二進(jìn)制代碼，是不是也應(yīng)該考慮兩種不同的壓縮包呢？一個是二進(jìn)制代碼，一個是源代碼。

維護(hù)穩(wěn)定分支部分的工作怎么辦？

穩(wěn)定的分支在社區(qū)經(jīng)常被遺忘，維護(hù)這些穩(wěn)定分支的團(tuán)隊得到的感謝比較少。然而穩(wěn)定分支的代碼運(yùn)行在許多OpenStack云環(huán)境下，它們對于向后兼容的后端遷移修復(fù)非常關(guān)鍵。

每一門語言都有自己發(fā)布庫的方式，管理兼容性的方式。當(dāng)為社區(qū)加入新的編程語言，與原有的其他團(tuán)隊之間的合作是至關(guān)重要的。

為新的語言設(shè)置CI管道

還有就是與基礎(chǔ)設(shè)施組討論設(shè)置CI（自動測試系統(tǒng)）管道。

這個任務(wù)可能是許多工作的基礎(chǔ)。為了解決之前的許多任務(wù)，有必要設(shè)置CI（自動測試系統(tǒng)）作業(yè)，這涉及與基礎(chǔ)架構(gòu)團(tuán)隊協(xié)調(diào)。后者是至關(guān)重要的。 基礎(chǔ)設(shè)施團(tuán)隊的參與對于添加任何新語言都至關(guān)重要，他們的反饋將在許多決策中發(fā)揮重要作用。

回顧一下為Python語言做的一些基礎(chǔ)工作，其實是大多數(shù)項目都需要做的事情。我希望致力于加入新語言的團(tuán)隊可以做一些通用性的事情，為以后跨多個項目的時候使用。

比如會有以下幾方面的通用性工作：

•Lint checkers
•Doc builders
•Release Pipelines

要做的似乎還有很多

把上面提到的方方面面都做到的話的確需要許多人力和時間。不幸的是，涉及到的許多團(tuán)隊真的騰不出手來做別的事情了，所以我覺得大部分工作將會由各組里多語言感興趣的人來貢獻(xiàn)出來的。無論如何，這些工作勢必耽誤每個團(tuán)隊的工作時間，即使是大部分的研究，文檔和補(bǔ)丁都是由有興趣的團(tuán)隊來自愿完成的。

整個社區(qū)花了多年時間讓Python處于目前的狀態(tài)。我不指望一個團(tuán)隊工作一個禮拜來把新的語言代碼加入到已經(jīng)用了六年的Python體系中。然而，機(jī)制已經(jīng)建立，團(tuán)隊也已經(jīng)存在，在一起協(xié)作下，上述的問題可能會在合理的時間點得到解決。

我希望這是個循序漸進(jìn)的過程，這就是我為什么強(qiáng)調(diào)需要經(jīng)過以上幾個步驟的原因。人有流動性，即使是做過承諾有時候也不管用，我認(rèn)為做這是最重要的是先做，然后在漸漸接受這門語言。

***，即使存在一個形式良好的添加新語言的過程，我仍然推薦優(yōu)先使用Python而不是其他語言。這與語言偏好無關(guān)，只是與我們社區(qū)中現(xiàn)有的知識的傳播有關(guān)，我相信這種知識是無價的，將這些知識變成一種新的語言需要幾年時間，相比之下優(yōu)化則是一個更容易的任務(wù)

創(chuàng)新對很多項目都很重要。我們也相信不可能永遠(yuǎn)保持原樣，語言的變化，項目的興起，項目的消亡等等。加入新語言這回事兒也是社區(qū)變化 的一部分，我也希望OpenStack社區(qū)盡可能以***的方式擁抱變革。但我希望是以一種相對保守的方式。我相信本文中提到的這些任務(wù)將會幫助大家未來以更快、更安全的方式來增加新的語言。

當(dāng)然，以上都是我的個人觀點，我現(xiàn)在越來越癡迷于明確預(yù)期。因此，我會起草并提交一份正式文檔到技術(shù)委員會。

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】