在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 由於篇幅過長，所以本文會著重於 kubernetes 原始碼的部分，而 Docker 相關的部分則會餘下篇文章來研究.
在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 本篇文章會針對後半部分，也就是所謂的 docker(dockerd) 本身再創建容器的時候，會如何處理其 DNS 相關的設定，透過閱讀 docker-ce 以及 libnetwork 相關的原始碼，不但能夠更清楚的釐清全部的運作原理，也能夠學習到 docker 底層實踐的過程與精神
AsyncConnection 此物件代表整個 connection，裡面提供了收送(Write/Read)兩個主要介面供應用層(OSD/MON等)使用外，裡面也處理了整個 Ceph Node收送封包的邏輯處理，這部分比較像是一個 finite state machine(FSM)，當前狀態是什麼時候，收到的封包是什麼，就切換到什麼狀態來處理。
此篇文章主要研究目前很熱門的 scale out storage 軟體 ceph 的網路架構。
Async 希望在與底層kernel socket進行I/O處理時是以 Async 的方式去運行，而不是像 Simple 一樣每條 connetion 都要開兩個 threads 來負責處理 read 跟 write。
延續上篇文章 (Ceph Network Architecture 研究(一))[https://www.hwchiu.com/ceph-network-i.html#more]，本文將繼續探討 Async 這種網路類型底層真的架構與概念，所以本文章也不會有太硬的程式碼解讀，反而會比較偏向概念性的分析。
Introduction
之前曾經發過一篇文章LXR Server With Multiple Projects，主要介紹如何在 Ubuntu 上面安裝 lxr 並且支援多個 projects。由於整個 lxr 的安裝過程複雜，除了本體外還牽扯到不少第三方程式套件，如 perl, database, www server，且大部份都是安裝完畢後就再也不會更動，唯一的更動應該就是更換要被 indexing 的 project而已。
Introduction
整個 DRBD 分成 kernel space 跟 user space。
本文延續之前研究 drbd 9.0 網路的工作流程，這篇文章主要在研究其 kernel space 中的行為與邏輯。
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以瞭解每個開放出來的 Restful API 該怎麼使用。相對於文件的更新速度，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
這篇文章用來介紹在 Fllodlight 中是如何去完成下列事情, 1)不使用 Spanning Tree Protocol 的方式也能夠正確的在有迴圈的網路拓樸中來傳輸封包，2) 針對任意兩個點對點的網路節點，能夠找到一條最短的路徑用來傳輸封。 這些事情在該控制器中，其實是透過計算一個 Tree 的方式來完成所謂的 Broadcast Tree, 藉此避免廣播風暴的問題，同時透過 Djikstra 的演算法來在拓樸中找到一個最短路徑來傳輸封包。
在floodlight這個openflow controller中，對於module之間的執行順序是如何決定的，這部分很重要
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部是如何轉送封包的，藉由 Topology 模組提供的 Global Topology 資訊, Floodlight 可以從該資訊中對於任何一個點到點的之間的連線找到一條傳送路徑。接者針對這傳送路徑上所有的交換機輸入對應的 Openflow 規則來幫忙轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部關於網路拓樸的處理，這些拓樸除了影響 Controller 怎麼看待整個網路之外，也會間接的影響該 Controoler 要如何去正確的轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
In this article, I will write down a example to descrip how to setup the LXR(Linux Cross Reference) with multiple projects support. In this configuration, your can view multiple projects' refernce in one LXR service.
Introduction
ovs-vsctl add-port br eth1
hmap 是一種hash bucket的資料結構，在 OpenvSwitch 中到處都可以看到其身影，，譬如 kernel space 中的 flow_key 就是透過這種結構來存放的。本文會檢視一下該 hamp 的結構，並且稍微看一下關於插入這個動作的原始碼
In this post, I try to study the soruce code of openvswitch to learn how does the openvswitch kernel module works.
這篇文章中，我們決定透過閱讀原始碼的方式，來瞭解 OpenvSwitch 操作上最常使用的指令，也就是 add-port 這個指令每次運行時，整個系統到底怎麼運行的。藉由閱讀原始碼的方式來釐清整個 OpenvSwitch 的架構，從 User-space 的程序到 Kerenel Space 的 Module, 這中間到底是怎麼處理的。
這篇文章帶領大家透過閱讀原始碼的方來學習如何 OpenvSwitch 是如何處理封包的，當底層的 Kernel Switch(datapath) 沒有辦法轉發封包時，要如何將該封包送到上層的 User Space Table 進行 Openflow 規則的查詢。這部份牽扯到資料如何橫跨於 User-Space 以及 Kernel-Space.
Question
Introduction
Introduction
有在接觸 AI 領域與 Python 程式設計的人，想必都對 Jupyter Notebook 這個應用工具不陌生。在某些特殊的情境下，會有部分的需求想要透過命令列直接執行該 Jupyter Notebook，由於 Jupyter Notebook 檔案本身不是一個被認得的執行檔，所以這時候都要特殊方法將該 Jupyter Notebook 轉換成 Python(IPython) 檔案來執行。 Jupyter Notebook 本身的工具就有提供這樣的功能可以來轉換，而本文想要介紹的是如何使用程式化的方式來轉換，透過自行撰寫 Python 腳本來轉換，可以讓我們在轉換的時候進行一些中間處理，譬如過濾些特殊用法，如IPython的語法。