SauceLabs selenium testing with selenium-webdriver

selenium 是用來做瀏覽器測試的工具,讓你可以安排一個流程在真實瀏覽器上運行來測試結果是否如預期,已經被大量用在 Web 的測試上,這已經許多年,也有許多教學了。

而在 selenium 的測試上,最方便的是能跨瀏覽器測試,但是最麻煩的是你要安排有很多瀏覽器的機器(或虛擬機器),並把環境部屬好,供 selenuim 運行。

而 saucelab 是一個雲端的測試平台,就是用來解決這個問題,他提供了隨時供你取用的運算資源,讓你隨時可以模擬各種平台不同版本的作業系統與瀏覽器,他是一個付費的服務,但是有免費試用的額度可以玩玩看。

這篇文章紀錄從頭到尾透過 nodejs 在本機建立建立一個 selenuim 的測試環境,最後在透過 saucelab 來測試其他作業系統與瀏覽器。
Continue reading…

VxLAN and nvGRE and STT

VxLAN:

nvGRE:

STT:

linux multipoint gre survey

最近在 survey 與 tunnel 相關的協定與網路虛擬化有關的,除了原有的 tunnel 以外,因應一些雲端應用現在還有 cisco vxlan、microsoft nvgre、nicira STT 等等為了嶄新目的所設計的協定。

但學習還是從根本下手,連 gre 都還沒有很懂,就先來看一下 gre 好了(其實是其他的都看不懂)。

Generic Routing Encapsulation 是 cisco 提出來的 tunnel 協定,採取點對點的方式,將兩個不同的網路透過 internet 串連起來,能形成一個虛擬的網路(不是指 VLAN),實際運作就如同一般 VPN 的應用所達到的效果一樣。如果需要要加密還能搭配 IPsec。

點對點指的是什麼點呢?兩邊子網路各提供一台主機(spoke)負責接收(decapsulate)與發送(encapsulate)。

什麼情況下這 spoke 會處理封包呢?

可以分為兩種模式, layer2 與 layer3,layer2 是針對區網的所有看得到的封包都進行轉送,layer3 則是 client 要將 broker 指定成該子網路的 gateway 才會轉送。

怎麼分別這兩種類型的 gre tunnel 呢?

最簡單的方式就是分辨 broker 的 tunnel interface 是否有設 IP 就能知道了, Layer 3 的有設, layer 2 的沒有。

在 linux 上?

linux 上只要透過 iproute 就能設定讓介面提供 layer 3 的 GRE 的 tunnel 了,而 layer 2 的部份目前我是透過 Open vSwitch 來做,如果用原本的 gretap 的話就要搭配 linux bridge 才能做到。

上述的都是基於 p2p 的做法,那標題寫得 multipoint gre 又是啥呢 🙂 ?

後來 cisco 又提出了 multipoint gre,讓一個 gre 的 tunnel 不只是 p2p ,而可以一個通道多台主機對連,讓設定變得更有彈性,而這個協定的發展似乎與 Dynamic Multipoint VPN 相關,麟瑞科技這篇文章有一些介紹。

接著我在 linux 上想尋找這協定的實作,結果發現一篇文章 Ethernet multipoint GRE over IP(in Google Groups)。似乎在核心最近的版本才有相關的 patch。他們有一些精彩的討論,剛好跟我最近想解決的問題相關,參與討論的包含了 patcher、ovs 的開發者、linux 網路相關的維護者,最終這個 patch 沒有被收納到核心,部份原因是跟 ovs 的存在有些衝突。

該 pacher 提案者提出一個概念,他認為 layer2 multipoint gre 應該要搭配 bridge 的學習機制,不應該無謂的一直將收到的封包像 hub 一樣傳到每個連接的 spoke,但他這樣獨立的實作這個概念與原先的 bridge 與 gre tunnel 的存在有點重複,又與 Open vSwitch 主要想處理的問題又有些衝突。但他還是有的自己的看法,希望此功能獨立存在,但最終還是被打槍了,而且真的讓 davem 覺得他很盧…。

這次在尋找 mailling list 的過程中感覺 gname 線上 web 閱讀介面有點不友善,只是好像其他的也都差不多~最後找到覺得比較好的是 http://www.gossamer-threads.com/lists/linux/kernel

另外也認識了一個人物,David S. Miller ,他在這些討論裡面擔任負責審核 patch 是否能進入核心的關鍵角色。以一個 Linux Kernel 開發的門外漢的角度,從這系列的討論中,讓我理解一些此環境的生態,開發者積極的想要自己的 Patch 被採用許要耗費多少心力去解釋,去獲取人家的認可,在沒有提出適當的理由,或者足夠的原因的程式,或許終究會被一道高牆擋下。

David S. Miller:I’m not applying your patch.