關於 QT License 看 Open source 界無法避免的議題

Source: Guide to the Total Cost of Ownership of Open-Source Software

 

關於 Open Source License 的議題在台灣的公司比較少去討論，但是對於國際大廠來說這是永遠無法避免的問題，在一切都要合規得前提下，再做任何技術選擇時，必然要把 License & cost 考量進去。

關於 Libvirt Event Registration for Java Binding 的碎碎念

圖片來源：新浪收藏-抽絲剝繭

使用Opensource 讓人又愛又恨的就是遇到bug和問題，通常到最後只有三種路：

1. 回報社群等人修好  (但是通常會等到天荒地老~~~老闆請你來是做啥的!)
2. 翻Mail list看以前有沒有人解決過，或有什麼建議  (Hello~~有"沒有人"遇過或修過~~)
3. 看source code 然後自己下去patch (我也想當沒有人，但是往往能力不足...Orz..)

話說 Libvirt 雖然有提供Event Registration 的機制和 Java Binding 的Library，但是兩的湊在一起就是不work啊！！

一跑下去就遇到以下錯誤：

libvir: Remote Driver error : adding cb to list
exception caught:org.libvirt.LibvirtException: adding cb to list
level:VIR_ERR_ERROR
code:VIR_ERR_RPC
domain:VIR_FROM_REMOTE
hasConn:false
hasDom:false
hasNet:false
message:adding cb to list
str1:%s
str2:adding cb to list
str3:null
int1:-1
int2:-1

一路Trace source code 往下，到了JNA那一層就斷了...囧rz...只好上網看看有沒有人遇到這個問題。

首先看到的就是Redhat 的bug report：

• virConnectDomainEventRegisterAny won't register the same callback for the same event but for different domains

再來 OpenStack 目前也有遇到這個問題：

• does not support events: adding cb to list spew in compute log (2013 Nov)

然後看到有人說要使用Event Registration 前，要先初始化 (不過舉的是C和Python的範例)

Make sure you have registered in the libvirt event loop (or set up your own) before registering for events

最後從Libvirt 的mail 爬出一連串的討論：

• [libvirt] [PATCH] Java bindings for domain events (2008 Nov 07) -->開始討論
• [libvirt] [PATCH 1/2] Java bindings for domain events
• [libvirt] [PATCH 2/2] Java bindings for domain events (2008 Nov 18) -->被打槍
• Re: [libvirt] [PATCH 1/2] Java bindings for domain events (2008 Dec)  —>沒下文
• [libvirt-users] Using Java bindings to event callback  (2010 Jul) —>沒回應
• [libvirt] [PATCH 0/2] Libvirt-java event handling (2011Jul) —> I think most drivers don't support that. We have a custom driver for our hypervisor and it works. 
• [libvirt] [libvirt-java] [PATCH 00/12] event support (2013 Jan) 
• Re: [libvirt] [libvirt-java] [PATCH 00/12] event support (2013 Mar) 
• [libvirt] [PATCH 2/3] Add event callback implementation based on virConnectDomainEventRegisterAny (2013 Mar)

Ps. 2013 版的那個Patch 有在Github上找到，但是試了一下還是有問題....


所以其實這是一篇碎碎念文，因為結論是目前Java Binding 無法支援這個功能，除非自己跳下去把它改好.....

Libvirt 開發前須知資料整理

source:wiki

開發前須知

Linux 最恐怖的就是軟體和Library 的版本相依性，以及要了解哪些事穩定的版本，哪些是實驗版本 。而Libvirt 就是魔王等級的，又複雜文件又不清楚，要注意的除了OS版本，libvirt 版本，以及相對應的hybervisor 版本....最後很多東西都得再程式和mail list 裡面挖出來

Libvirt Stable version

0.9.6.x—>0.9.11.x—>0.9.12.x—>0.10.2.x—>1.0.5.x—>1.1.3.x

CentOS 6.4 使用 0.10.2.x 的版本
Mac OSX 使用Brew 安裝的版本是 1.1.4

如果要使用Java Binding 來開發Libvirt 這邊也有版本需要注意(git repository)
Java Binding —> Libvirt version

0.4.7.x —> 0.8.2
0.4.8.x —> 0.9.12
0.4.9.x —> 0.10.2.x
0.5.x —> 1.1.x

相關開發文件

• Libvirt API   
• Application Development Guide (頗舊，最好直接看Code...Orz..) 
• Java Binding Doc

Host 設定

1. 設定遠端管理機制：Remote support (Connection)

• How to configure management access to libvirt through SSH  (最簡單)
• (CentOS 6 以後改用這個) Configuring management access via PolicyKit
• Setting up libvirt for TLS (Encryption & Authentication)  
• VNCTLSSetup

2. 測試連線機制 (Connection URIs)

So to connect to the daemon, one of two different URIs is used:

   * qemu:///system connects to a system mode daemon.
   * qemu:///session connects to a session mode daemon.
   * qemu:///session                      (local access to per-user instance)
   * qemu+unix:///session                 (local access to per-user instance)
   * qemu:///system                       (local access to system instance)
   * qemu+unix:///system                  (local access to system instance)
   * qemu://example.com/system            (remote access, TLS/x509)
   * qemu+tcp://example.com/system        (remote access, SASl/Kerberos)
   * qemu+ssh://root@example.com/system   (remote access, SSH tunnelled)

[Update] 2013.12.05

如果使用Mac OSX 安裝Libvirt 去連KVM 會出現以下錯誤訊息：

Connecting to the server will result in an error : "hangup / error event on socket".

It turns out that the macosx client assumes the socket resides in /usr/local/lib whereas the ubuntu server has the socket in /var/run/libvirt/libvirt-sock .

請改用下面的方式連線：

> virsh -c qemu+ssh://root@libvirthost/system?socket=/var/run/libvirt/libvirt-sock

[參考連結]


PS1. 如果利用Libvrit  無法透過API 把 qemu+ssh 所需要的 password 帶過去[Referecne-link]

As I said before, the auth callback you can pass to virConnectOpenAuth
is not used for the libvirt SSH remote transport authentication. The
same it true for the TCP transport, it uses SASL for authentication by
default.

PS2. Java Binding 其實有很多功能都沒有implement

Known api calls to be missing
 * LIBVIRT_0.1.0
 * virDefaultErrorFunc
 * virConnCopyLastError
 * virFreeError
 *
 * LIBVIRT_0.4.2
 * virDomainBlockPeek
 * virDomainMemoryPeek
 *
 * LIBVIRT_0_5.0
 * virEventRegisterImpl
 * virConnectDomainEventRegister
 * virConnectDomainEventDeregister
 *
 * LIBVIRT_0.6.0
 * virConnectRef
 * virDomainRef
 * virNetworkRef
 * virStoragePoolRef
 * virStorageVolRef
 * virNodeDeviceRef
 *
 * LIBVIRT_0.6.1
 * virFreeError
 * virSaveLastError
 * virDomainGetSecurityLabel;
 * virNodeGetSecurityModel;
 *
 * LIBVIRT_0.6.4
 * virInterfaceRef
 *
 * LIBVIRT_0.7.1
 * virSecretRef
 *
 * LIBVIRT_0.7.2
 * virStreamRef
 *
 * LIBVIRT_0.8.0
 * virNWFilterRef

知識分享回饋社群

圖片來源：wikimedia

今天早上看到這篇文章 - 五件在我靠程式吃飯之前就該知道的事 ，對於下面這段特別有感覺。(話說我的文章是不是也該嘗試來寫寫看xxx應該知道的幾件事...:P )。

我的生涯早期，我犯了一個錯誤，就是不怎麼去向社群尋求幫助，也不為他人提供幫助。我一向樂於幫助我的同事，也在不同的工作崗位上也非常善於交際，但活動範圍從來沒有超出過公司。
我在我的生涯中花了大量的時間，試圖在一個特定的公司進行投資，卻沒能將我的時間投資在我參與的軟體開發社群中。
我花了很多時間，做關於技術或者是最佳實踐的內部 presentation，而這些時間原本可以用來製作可以服務於社群的內容和材料，同時也能給我帶來工作上的認可。
我也犯了另一個錯誤，就是認為自己沒什麼有價值的東西去貢獻。
我和很多剛入行的開發者聊過，有時候我覺得，比起我們這些”老油條“，他們有更多的東西去貢獻給社群，因為他們更理解其他初學者蛋疼的問題。
如果我可以重來一遍，我一定會在我的生涯中更早、更多地參與各種會議和使用者群。我會更早地開始寫部落格，並利用我的大部分學習時間去建立專案和資源，去幫助別人而不是只讀書。

看到上面那個 "認為自己沒有什麼有價值的東西去貢獻"，真的很想大喊 "真的!! 好多人都這麼想 ，這真的是不對的!! "。

其實對於我們搞技術的人來說，最容易產生並且分享出來的內容就是學習筆記，小到操作Linux的指令集，大到安裝整個Hadoop Cluster，這些內容都是非常值得分享的，不要認為太簡單不重要，因為你什麼時候會幫到人你都不知道。

而且也唯有當你把資訊整理過後再分享出來，才能促成整個知識傳遞的正向循環，就像Open source 一樣，有人願意分享出來，然後其他人經過參考和學習後，可以激盪出更多的火花和更新想法產生更多更好的專案和程式。

話說在加入上一間公司之前，寫Bloger對我來說可能只是偶而用來記錄遊記和發發牢騷的地方，並沒有特定發文的週期，沒有壓力也沒有目標就很容易懶散，但是自從嘗試要開始透過Bloger宣傳自己開發的產品時(MeshCloud) ，我就變成就有了一個目標，就會開始努力寫文章，努力找梗，努力研究各種流量分析和SEO的方法，漸漸的每天固定監看各種流量和數值變成了一種習慣，在看文章和各種資料的時候也會想說 " 嗯～這個題材不錯可以拿來用...這個很有梗~ "，於是想梗和內容就變成了生活的一部分 。
 任何的梗和筆記都可以先收藏到筆記本裡，像我都是用Evernote把我的想法和筆記分類整理好，等到整理完或是哪天有空了就可以拿出來變成一篇可以分享的文章。

所以在這邊真心建議有剛好有看到這篇的朋友，真可以把你們手邊的筆記整理一下Release出來分享給大家看，幫助社群也幫助自己。(雖說大家也不一定真的有興趣看...XD 但是難說哪天就是會幫到人~:P )

[筆記] 如何把你的open source 專案 納入maven central repo

要如何把你的open source 專案 納入maven central repo呢？常在很多open source 專案的parent pom.xml看到這樣的設定：

 <parent>
    <groupid>org.sonatype.oss</groupid>
    <artifactid>oss-parent</artifactid>
    <version>7</version>
  </parent>

原來這就是把專案加入maven repository 的方式，現在maven central repository 是由sonatype這個組織在管理，關於sonatype的介紹如下：

sonatype OSSRH (OSS Repository Hosting Service) uses Nexus to provide Maven repository hosting service for open source projects: https://oss.sonatype.org/. You can deploy snapshots, stage releases, and promote your releases so they will be synced to The Central Repository. All you need to do is to sign up a Sonatype JIRA account, create a JIRA ticket and make some POM/settings configuration. This document will guide you step by step for the details.

參考這份文件Sonatype OSS Maven Repository Usage Guide，步驟如下：

1. 決定你Release 的 License

2. 申請一個Sonatype JIRA account

3. Create a JIRA ticket

4. 設定要deploy 到哪個repository

ApacheCon2013 - Hadoop and HBase on the Cloud: A Case Study on Performance and Isolation

圖片來源：改編自網路圖片

(這篇真的壓了好久喔....Orz...沒時間好好研究和收集這方面的資料...)

還記得之前我之前曾經寫過兩篇文章：到底功夫熊貓(Xen)踢不踢的動大象(Hadoop)呢和"要使用大象，真的得養頭大象嗎？為何不使用AWS EMR，剛好這次ApacheCon2013就有談到這個題目：

Hadoop and HBase on the Cloud: A Case Study on Performance and Isolation.

by Konstantin Shvachko, Jagane Sundar

這個talk討論的正是如何用虛擬化提高Hadoop的使用效能!? 一般來說談到虛擬化，第一直覺反應通常是使用後往往會拉低使用效能，怎麼反而還可以提高呢？所以這個題目讓我特別感興趣，讓我們來看看他的論點。

首先他的假設前提是 "Low average CPU utilization on Hadoop Clusters"，因為他認為Disk I/O和Network 都是可以透過設計和規劃提高一定的效能，但是CPU utilization is bad，他列兩點原因：

• IO bound workloads preclude form using more cpu time
• Cluster provisioning:
• peak-local performance vs average utilization trade-off

不過他下面show的圖只能說使用Virtualization 會更有效率的使用CPU，就把它操的很忙....

所以結論是...?

不過其實上面的這些假設與如何實現不是重點，重點是聽到下面幾個不錯的Benchmark提供參考，因為當你安裝好Hadoop後，你要怎麼知道你的Hadoop設定的對不對，Performance是好不好？是否有達到一定的水平？

• DFSIO (Standard Hadoop benchmark measuring HDFS performance)
• YCSB (Yadhoo Cloud service benchmark)
• TeraSort benchmark suite  - Sort Benchmark Home Page 
• NameNode benchmark  ( src/test/org/apache/hadoop/hdfs/NNBench.java) 
• MapReduce benchmark  (src/test/org/apache/hadoop/mapred/MRBench.java)

Reference:
[1] How to Benchmark a Hadoop Cluster
[2] How can I run a DFSIO test on MapR?
[3] Benchmarking - DFSIO, Terasort
[4] Benchmarking Hadoop & HBase on Violin
[5] Apache hadoop performance-tuning methodologies and best practices
[6] AMD Hadoop Performance Tuning Guide
[7] Benchmarking and Stress Testing an Hadoop Cluster With TeraSort, TestDFSIO & Co.

ApacheCon2013 - Mastering Sqoop for Data Transfer for Big Data

圖片來源：siliconweek

這個Talk同樣是由Cloudera 的工程師 Kathleen Ting 和 Arvind Prabhakar 來輪流報告 (我也不知道為啥他們同一份投影片要輪流穿插講)，主講的題目是Mastering Sqoop for Data Transfer for Big Data，不過主要的內容是在講解Sqoop1 的缺陷，以及目前他們在發展的Sqoop2 預計怎麼改上Sqoop1的缺陷。

Sqoop的主要功能就是 SQL to Hadoop and vice versa，而Sqoop1的特色如下：

• Base on connectors
• Responsible for meta data lookup,and data transport
• Majority of connection are JDBC based 
• Connectors responsible for all supported functionality
• Hbase import, Avro Support

也就是說Sqoop1 其實很單純只是一個Client side的工具，都必須在Local 執行，且需要Root的權限。此外如下圖所示

圖片來源：sqoop

而 Sqoop1 目前所遇到的挑戰：

• 只使用原生的JDBC，沒有使用每個平台特定的Driver
• 例如Oracle 的Driver 所提供的最佳化。
• 安全問題 
• 用明碼記錄帳號密碼，甚至把帳號密碼設定在Config File裡
• Type mapping is not clearly :
• Client needs access to Hadoop binaries configuration and database
• JDBC model is enforced (這樣可能造成要符合Hadoop 模式會有問題)
• Non-uniform funtonality
• Difference connectors support different capability
• Overlap / Duplicated functionality
• Different connectors may implement same capabilities differently

上述的問題都是由 sqoop1 的歷史包袱所造成，因為一開始sqoop是設計給都是給power user 使用，主要用在內部系統有大量的資料在轉移的需求，所以就很少考慮到安全性問題。

為了解決這些問題，在Cloudera所主導開始了 Sqoop 2  (CDH4)的版本，這個版本主要的改變是多了一個Server 當中間者的架構，很多東西都儲存在Server 那邊，目標就是把sqoop從一個Tool變成一個Service，整個架構改成如下圖所示：

圖片來源：sqoop

圖片來源：ApacheCon 2013

Design goals

• Ease of Use
• Uniform functionality (不需要specific table?)
• domain specific interactions 
• Ease of Extension 
• No low-level Hadoop knowledge needed
• No functional overlap between connectors
• Security and separation of Concerns
• Role based access and use

主要的改進如下：(不過有些我也還不是很瞭解)


Sqoop提供兩種連線方式 (Connection vs Job meta)：

• Connection (distinct per database)
• Job (distinct per table)

運作原理如下：

1. Connectors register metadata
2. Metadata enables creation of connections and jobs
3. Connections and jobs stored in metadata repository
4. Operator runs jobs that use appropriate connections
5. Admin set policy for connection use

在當下我不太了解，所以有跟講者確認，她說 Connector 由admin 去產生， 工作由operator 拿這個connector 去工作，這樣就不用洩漏帳號密碼。

所以Security方面改善如下：

Support for secure access to external system via role-based access to connection objects

• Administrator create/edit/delete connections
• Operator use connection (session base?這點待確認)

Usability $ Extensibity:

• Connections and jobs use domain specific inputs (Tables, Operations, etc) 
• Domain isolation and thus easy to understand and use
• Connectors work with intermediate Data format
• Any downstream functionality needed is provide by swoop framework

所以新版的Sqoop還是有許多地方需要在研究了解~ (Sqoop2目前是1.99版~XD )

最後幫他們宣傳一下sqoop2 專案還很缺人，現在加入還蠻有機會變commiter唷~XD

Reference:
[1] Apache Sqoop: Highlights of Sqoop 2
[2] Sqoop2 apache wiki

ApacheCon2013 - Text Lacks Empathy - Noirin Plunkett

延續上一篇"How to Delegate Like a Boss"，這個Talk也是關於Open source 專案營運管理會遇到的問題，也就是所謂的溝通問題，因為Open Source 專案的開發人員散布在全世界，最常使用的溝通管道不是透過Email就是IRC ，所以如何透過文字有效的溝通就是一個很重要的課題 - Text Lacks Empathy 

而這位紅髮姑娘 Noirin Plunkett 的主要職業是一個Technical writer，所以她也特別明白文字的力量，和該如何注意用字遣詞。就如同上圖都是在講Ship 和 Shipping 其實都有很多意義。

最重要的注意的是：We are not writer , We speak with our fingers. ..

同樣的字句，通常透過不同的語調就會有不同的意思，但是對於讀者來說可能都會有自己的解讀，比如說 sure it's fine 語調不同就會有不同的意思，所以用這些字句似乎可能得小心。

 下面是她建議的一個Email Template格式 (其實很普通常見)

---

Tact template

Hello $your_name,

$body

Thanks,

$my_name

---

所以下面幾點就是在溝通時要注意的：

Using Social Code
(在問別人狀況時，也許可以先說自己的狀況，所以老外最愛問人家how are you? How do you do?)

Listener ,try not to second guess. 
(不要想太多，對於人家的文字有過度解讀)

They don't know how you feel. State your emotions
(要清楚的說出自己的心情，不然人家從字面不知道你真正的意思)

Paraphrase (釋義)
(在聽到別人的話後，可以用你理解的話再反問一次，來確定是不是他的意思)

她也覺得顏文字非常很有力，可以多加運用

Try to be nice 
(就算人家是grek 但是還是要對他好，不然永遠不會有好的溝通)

其實最好的溝通方式還是當面，用Email通常已經是最不得已的方式
(Email --> IM or IRC--> Voice -->video --> Real Life)

所以她認 yahoo目前也是因為這樣的原因才要取消remote work，因為面對面溝通會比較好，對於外國人來說，最常看見的就是大家一起到公司，就算再玩，都可以建立關係和trust，這樣之後不管是工作和合作起來才會比較方便和順利。

It's not a competition 
(所以發email 的速度慢一點，不要一直cc bcc 來去，如果發的頻率太高，到時候人家就會不想看你的mail，想說這傢伙總是用寄信的)

Use the passive
(用被動語句 "The build broken"  ，對事不對人)

If it doesn't matter, do it their way.
If it doesn't matter and you still want to do it your way, you're lying.
If you care , say I don't want do your way, because following reason…..

ApacheCon2013 - How to Delegate, Like a Boss Deb Nicholson

圖片來源：businessbyjanice

Open Source 專案通常也會有所謂的Team Leader 的角色，但是這個Team Leader 的角色通常不像公司的Team Leader一樣有那麼具有權力，或是對於Team merber有制約力，所以如何管理一個Open Source Project 就變成一個難題。

因此這次ApacheCon 就有一整個Track 專門在談論針對Open Soruce Project 如何管理/營運/發展。而這個Talk就是在談論如何像老闆一樣授權 (How to Delegate, Like a Boss - Deb Nicholson)，以下是我記錄的筆記。


身為一個Team leader 或是mentor，不應該把自己當老闆看待，應該視自己為一個協調中介者。

不要等到你透支了才想到要授權，一開始就要授權！ (Don't wait delegate until you burn out. Delegate at first!)

由馬斯洛理論來看，通常會來參加 Apache 專案的都是為了自我實現(Self-actualization)，贏得尊重(Esteem)，增加社交網路(Social)，比較少是為了較低層次的Safety 和 Physiological，所以對於這些人，最好的獎勵就是稱讚：

Thank you as the free money!

對於Team Leader 要學會稱讚人的藝術，她舉個例子，稱讚就像在Code review一樣，要講詳細的內容具體的成就，而不是只是說好或不好。

Question welcome . more document on wiki can help you reduce your jobs.

雖然平常的分工可能都是把工作切的很細(Tie micro tasks to macro goals)，但是務必要想辦法讓他們知道Total Picture Goal，讓他們知道他們做的東西都是為了大目標，不是在做無聊的事，知識工作者(尤其是Hacker / Geek )都不喜歡只當一個小螺絲釘，希望能有參與感。

如何控制大家的活動或意向，比如說用比賽或是成就系統，比如說現在很少人在review patch code，也許可以舉辦一個比賽，給大家分數。Review 越多的的人可以排名越前面 (因為大家都為了榮耀)


最後她還demo了一個社群討論專案信產生器 (Live delegating)，不過似乎沒有Open Source出來~XD


Reference：
[1] How to Delegate, Like a Boss

ApacheCon2013 - Apache in Business Panel

ApacheCon 這一場Business Panel 主要是邀請幾間把他們公司產品Open Source 出去的大廠，所以還蠻值得一聽的，畢竟對於公司來說最常問的問題就是參與Open Source有啥好處，可以帶來啥商業價值？如何跟社群共處等問題....

整個Panel是由主持人準備幾個問題，然後由每間公司分別回答。而我也盡量用我的聽力把重點記錄整理下來。

開場白：Apache 的精神就是不被任何人擁有，大家一起成長

---

你們覺得Apache怎麼看 Business vs Open source

Bertrand Delacretaz (Adobe): 目前Adobe 90%專案都是使用或跟apache 專案有關，對於adobe認為，apache 的專案都是基礎共通的部份，每天公司可以在上面加值應用，所以不會牴觸

Phil Robb (HP) : 因為這些open source 的user 就是他們自己本身，所以市場本來就很清楚，然後為了自己使用方便，所以會更努力的讓這個程式更好

Mark Hinkle(Citrix): 如果你加入open source 你可以跟user 更接近，使用者可以更容易加入你，給你意見和幫你測試，Cloudstack 之所以要加入apache，因為apache 的方式與流程，很有公信力，對於open source 成長很有幫助，也不像GPL那麼有限制

---

加入了Apache 和open source 有啥影響

Mark Hinkle(Citrix) : 當然一開始每天都在掙扎，因為有點失去了自主的控制，但是只要follow apache 的方式，了解apache的文化，的確還是有用的

Phil Robb(HP) : 要學會跟社群相處，學會怎麼溝通和推動產品的方向

Bertrand Delacretaz (Adobe): 跟傳統的公司開發差很多，因為不是中央集權，這是一個分散式的架構，所以對於產品的開發與release 的管理方式就要因應有所改變，因為你不能壓了時間就要求大家一定要release，因為很多人都是義務幫忙的。

Phil Robb(HP) : 發現省錢是越來越不重要，反而是要跟工程師學會越來越彈性，因為對於軟體公司這些社群都是資產，會幫助HP。整個apache 的方法，不管對於Manager 和 Architect 都是跟以往很不一樣，必須要學習怎麼分散式的工作，但是Open source 已經是趨勢無法抵擋只能擁抱

Bertrand Delacretaz (Adobe): 我同意花費不再是專注於省錢，花多少錢，而是專注於軟體的功能，可以解決什麼問題，因為很多傳統的軟體工程方式，估價方式幾乎都不管用(永遠會落後進度)，此外要教會員工怎麼與社群一起工作開發專案，也是一個挑戰，但是公司最後還是會從中的到益處

結論：

對於軟體產業的cost 最花錢的的是行銷和客戶關係，反而不是RD人事費用，但是加入了社群後，這些花費反而可以解少，透過apache 的光環就自己被宣傳，使用者自己會來使用，測試，回饋，此外如果要聘用好的工程師，最容易驗證的方法就是從open source community 去找到人才，因為這個人的品質，能力是被大家驗證和所見的。

---

Apache 該如何在教育界推廣

對於美國學生來說，目前對於工程師Geek 的type都是覺得不酷的，所以還是很少人願意投入，所以這也是apache foundation想要嘗試解決的問題，而且透過apache的方式，人來自全世界各種人，所以可以增加多元性(人種，性別…等)。

apache  之後會有什麼計畫，類似童子軍一樣，從教育來改變嘛？

但是Apache不用像一般公司一樣，一定需要所謂的未來發展與十年願景之類~:P (像是IBM每年都會有啥趨勢預測)

但是apache 本身就由 User 和 Developer 的組合，趨勢就是由這邊去產生的，所以是由下而上去推動，不是由上而下推動

所以apache foundation 的任務不是要往哪裡方展，基金會唯一的目標就是協助發展更好的軟體，所以方向還是由工程師去推動

所以不管是獨立開發者和企業都對等重要的~

---

最後開放的Q&A：

有人問，這些公司怎麼看待Github，同樣是Open Source 怎樣的專案會選擇放入Apache？

Bertrand Delacretaz (Adobe): 對於公司來說，通常是長期基礎發展的就會放入apache，但是如果是短期實驗之類的就會放入github

Mark Hinkle(Citrix) :Github 對 Citrix 來說是專門用來發展branch 和 plugin 的地方，讓使用者可以自由發展發揮創意的地方

Bertrand Delacretaz (Adobe): Adobe 提醒，把東西放在Github要小心，因為對於軟體的擁有權，使用權…等，是不確定的有很多模糊地帶，所以是很重要的東西放上去要小心

ApacheCon2013 - Continuous Delivery with Maven, Puppet and Tomcat

Source：Carlos Sanchez - Continuous Delivery with Maven, Puppet and Tomcat

參加ApacheCon2013的筆記持續整理消化中....Orz..

話說在DevOps 的概念裡面本來就有包含QA的概念，不過很多時候卻被人誤解成，不需要QA或者是QA不重要，因此講者就在投影片引用一句話：

To make error is human. To propagate error to all server in automatic way is  Devops

所以越是自動化的部屬，就越需要QA的參與，所以講者就特別把QA獨立出來強調，因此才有DevQaOps的詞..XD 其實目的都是為了能達到Agile - Continuous Delivery 的境界。

雖然之前我有整理過一篇文章關於DevOps的工具與技術 -  Continuous delivery - tools and techniques ，但是對於這塊的著墨還是略嫌不足，而這次參加這個Session

這篇文章列出一堆幫助DevOps的工具與技術，而這個Session 雖然題目是寫Maven + Puppet + Tomcat 的組合，但是裡面主要介紹必較新奇的技術卻是 "Puppet + vagrant" 的組合，透過Puppet + vagrant 的組合能快速的建立vm環境和開發環境，加速複製和重建的時間，然後也可以利用puppet 控制maven 的安裝與控制，詳細的範例可以參考講者放在Github上的範例專案：

• Continuous Delivery with Maven, Puppet and Tomcat
• https://github.com/carlossg/continuous-delivery
• puppet + vagrant + maven 的組合
• https://github.com/maestrodev/puppet-maven

延伸閱讀：

• From Dev to DevOps with Maven and Puppet
• Provisioning Maven artifacts with Puppet

投影片：

Continuous Delivery with Maven, Puppet and Tomcat - ApacheCon NA 2013 from Carlos Sanchez

後記：

因為筆者都在介紹Puppet我就好奇，那Chef呢？因為這也是常見常聽到的技術，所以我就順便Google了 Chef 與 Puppet之間的差異。

• Chef vs Puppet – my take on the holy war
• Puppet or Chef?
• What is the difference between Chef and Puppet in configuration management software?
• Puppet versus Chef: 10 reasons why Puppet wins

簡單來說就是Chef 是新公司做出來的產品，有著跟Puppet相同的目標但是不同的技術，所以Puppet陣營的說法就是Chef沒有經過大型系統Deploy 的驗證與知名公司的背書 (不過最近Facebook採用了~:P)

所以同樣的也有Chef 跟Maven 整合的專案和套件：

• https://github.com/opscode-cookbooks/maven
• https://github.com/bryanwb/chef-maven-bin#readme

觀察各公司在Hadoop Ecosystem 的committer 與PMC 數量

圖片來源：Datameer 2013

相信這張圖大家應該都看過，是關於Hadoop Ecosystem technology partnerships之間的關係，第一名的是Cloudera。

剛好今天收到一封信說Hortonwork在Hadoop 專案的數量遠遠超過Cloudera，我就在想這樣看不準啊，因為cloudera在其他專案也有投入許多人力啊！？於是就燃起我一定要察個水落石出的念頭！！(工程師魂~~~~~)

剛好這也算是由另一個角度來分析，藉由觀察各公司在Hadoop Ecosystem (個專案) 的Commiter 與PMC 數量，來看個公司的主力方向以及參與程度。

整理的方法，就是收集Hadoop ecosystem 比較主要專案的PMC 與 committer 名單，雖然發現有幾個committer有跨專案，不過這邊最主要是要比較每間公司佔各專案的人數，所以就先不管混在一起計算(其實是偷懶....)，另外我也只計算幾個人數比較多的大公司，其他小公司或獨立開發者就沒特別列出來。

Ambari	Hortonworks	18
	IBM	2
Avro	Cloudera	4
Pig	Hortonworks	5
	Cloudera	1
	IBM	1
	Twitter	3
	Yahoo	3
Hive	Facebook	6
	Hoetonwork	1
Sqoop	Cloudera	9
Mahout	LinkedIn	2
HCatalog	Facebook	1
	Hortonworks	6
	Twitter	1
	Yahoo	2
Oozie	Cloudera	3
	Hortonworks	2
	Yahoo	3
	MS	2
Flume	Cloudera	12
BigTop	Cloudera	8
	Facebook	2
	Hortonworks	3
ZooKeeper	Cloudera	4
	Hortonworks	2
	Yahoo	6
Hbase	Cloudera	9
	Facebook	5
	Hortonworks	4
Hadoop PMC	Cloudera	7
	Facebook	3 + 2
	Hortonworks	13+ 4
	Yahoo	3 +7
	IBM	0+ 3

--------------------------------------
所以最後統計結果如下，果然還是Hortonwork 大勝！！

Hortonworks	61
Cloudera	48
Yahoo	27
Facebook	17
IBM	6
Twitter	9
LinkedIn	4

報告完畢~~我真無聊....XD

ApacheCon2013 - About BigTop

參加Conference要觀察一個技術或是專案的受重視程度，通常可以藉由幾個指標來觀察：

1. Session Room的安排 (越熱門的會議室通常越大間，越熱門的越早報告)
2. 類似題目sharing 次數 (越熱門的題目通常會被分享比較多次)

而這次參加ApacheCon最明顯的感受就是關於Bigtop 的受重視程度，因為光是Bigtop相關的題目就有三四場：

• Build & Deploy your own big data distribution with Apache Bigtop 
• Getting Hadoop, Hive and Hbase up and running in less than 15 min  [投影片]
• Lessons in Apache Software Integration [投影片]

三場的內容整理如下：

Why Bigtop ?

首先先從Hadoop的痛開始說起，傳統安裝Hadoop & Ecosystem 都會從Apache網站下載tar開始，然後接下來的步驟可能如下：

1. 下載安裝Hadoop
2. 設定環境變數 (當發現出現一堆error message 才會想起什麼環境變數忘了設定)
3. 設定HDFS權限 (當發現權限錯誤時才會想起要設定權限)
4. 如果要安裝Hive 就會遇到版本問題 (安裝其他ecosystem也常發生這些問題...Orz..)

所以社群就發現這不是跟當年的Linux一樣嘛？！最一開始Linux 都得要自己去下載套件，自己去Build每個套件，找出相依性....

  圖片來源：Bigtop

這種痛苦直到Debain出現才解決，除了提供一個整合的安裝還境外，由於是Debain完全由社群所貢獻，並不會由特定公司所把持，仍可以保持自由軟體的特性，但是也歡迎其他公司另外基於Debain上再做出更好的產(例如：ubuntu)。畢竟對於大部分的使用者來說，能用apt-get install 來安裝軟體是最好的，誰還會想由 tar ball來安裝呢？因為還得解決一堆相依性的問題。

圖片來源：Bigtop

所以BigTop 的概念就是類似Debain 的角色，要靠社群的力量來完成一個套件，其他公司如Cloudera和Hortoneworks ...等，可以基於Bigtop上加值和再開發。

所以Bigtop的定位就是：

Bigtop make building block to distribution

想像以後如果想要安裝任何Hadoop ecosystem時，只要下以下的指令，不是很棒嘛：

# bigtop lanuch-cluster -config ./hbase.ini

Key challenges

有願景是好的，不過Bigtop專案目前也遇到以下許多問題：

• A really drivers set of components
• High churn APIs 
• 不像Linux 有一個統一的架構，大家都不知道hadoop的最終方向，都是邊走邊改，所以API之間的相容性永遠是問題
• Asynchronous development cycles.
• 每個專案由於熱門程度不同，開法速度也不一樣，所以在升級上很難做到同步一致。
• Combinatorial explosion of dependency
• 永遠有各種版本的組合，也永遠會有不同的Bug
• Java based
• Java 開源專案最怕的 dependency 地獄，就算用 maven 也會有衝突的問題，最有常遇到的例子就是slf4j 和 log4j版本的問題
• Fundamentally distributed application
• Apache 的好處就是提供各式各樣的專案和building block，但是缺點就是太多了，你必須到市場去慢慢挑選你要怎麼整合，一個Architecture 就像一個廚師，你必須先知道每個食材的特色，和相互之間的關係，你才可以知道要挑什麼食材煮一套菜。

所以Bigtop的願景怎麼實現？這個專案到底要提供什麼？

• Integration 
• Build (make, Maven)
• Packaging (RPM, DEB)
• Deployment (Puppet)
• Testing (integration Test)
• A continuous integration Jenkins server 

所以目前Bigtop所使用的方法是一步一步慢慢推進，Embrace asynchronous nature (擁抱不同不的Hadoop)，總是找出一個最好的build ，然後再每次慢慢改一個lib 來測試推進。

Ps. 講者特別再會場徵求

目前Bigtop的Jenkins和測試整環境放在EC2 由cloudera提供，他們也歡迎任何公司/學術機構提供Test Case (放在Hadoop 跑的Real Case)，讓他們放在Jenkins 上持續的跑整合測試。



延伸閱讀：
[1] What is Bigtop, and Why Should You Care
[2] How to install Hadoop distribution from Bigtop 

ApacheCon 2013 BarCamp 初體驗

圖片來源：Apache barcamp Portland wiki

這是我第一次參加barcamp，之前完全沒聽過，也不了解裡面的內容，所以在參加前還先上網研究了一下到底barcamp 都在做什麼，節錄規則如下：

1. 你必須做關於 BarCamp部落格。
2. 如果你想要介紹，你必須將你的主題以及名稱寫在簡報上。
3. 自我介紹只講三個詞！請先想一下要用哪三個詞來表達自己關心的事情
4. 不預先排定議程，也不僅僅來當個過客！
5. 除非影響到其他人的說話時間，不然講者可以盡情地講！
6. 第一次參加 Barcamp 的人們，請一定要講些東西

關於1,2,4,5都還ok，但是一看到3,6就有點峱峱的....

不過因為Apache  的 mini Barcamp有 Expedia 贊助自助霸和飲酒霸(啤酒和紅酒)，衝著時食物就硬著頭皮上了！XDD

首先大會開始會有一個主持人 (主要是負責控制時間)，然後大家亂哄哄的開始報名想要討論的題目，然後就會投票主持人幫忙記票和排時間，下圖紅色圈起來的就是會議議程表(很Agile 的fu)，然後紅色頭髮那位就是主持人 (叫做Nóirín)~XD

最後排定了，幾個討論的題目，然後主持人就會依照上面的時間來提醒大家，然後再時間內大家都可以踴躍發言和分享。

看老外嘴砲討論真的還蠻有趣的，他們都還蠻喜歡針對嚴肅的議題做討論，然後問題和回答都很犀利，如果場景回到台灣，可能都是場面一片和諧，大家都不好意思說話，說的也都是場面話？(不過大陸人這點就比較像老外，問問題很不客氣的~:P)

對我印象最深刻的幾個議題：

• GPL2 vs. Apache License v2 的比較
• 為什麼越來越多專案轉移到Apache License
• 怎麼看待individual contribution 和 company contributions
• 討論政府是否可以像Open source這樣運行，同樣的Open source 在管理上面是否適用所謂民主的表決？

通常想發言的就會舉手，但是太溫和還是會被插話~:P

其實，除了少數幾個人比較踴躍發言外，大部分的人都鄉民一樣，拉板凳拿啤酒看好戲...XD

我大概是太累了眼殘...把PALE ALE...自動解讀成APPLE....想說蘋果口味啤酒一定要喝喝看，結果好難喝.....Orz..

ApacheCon 2013 Keynote - Scaling: Lessons Learned and Their Applications to Apache Culture

話說老外的投影片真的都有許多有趣的東西，講者Theo Schlossnagle開場的這張投影片超好笑，講者把自己各個時期的照片都貼出來 (因為他很有名，也到處到各個會議演講，可是都長得差超多!!)，老外真的很厲害怎麼可以每張照片都差那麼多。

Keynote的主題是 Scaling: Lessons Learned and Their Applications to Apache Culture，主要是在分享在開發系統的經驗和身為工程師應該要注意不要走走火入魔。


以下是我對他的演講的一些筆記：

Apache  的精神是解決真實世界的問題 (Solve the real world problem)，而不是追求程式的完美和展現自我能力，因此他說：

No exceptional !!  Your code is elegant but my code is fucking work

此外，針對自己寫的程式，不要過放太多情感和忠誠度，他就只是程式，他不是你的小孩，他可以長的很醜，他是可以被丟棄的。再一次他只是用來解決問題的！

Your code is just a code, it is not a child it can be ugly it can be disposed of it requires no loyalty. It only use to solve problem.

我們工程師太常專注於追求技術，而忽略了他們所面對的問題，太長專注於要用哪種語言，要用哪種framework (小弟自首...Orz..)

We engineers too often focus on the technologies they love instead of the problem they face. Code too much focus is placed on which language and which framework is used.

我們的工作是告訴電腦該做什麼事！

Our job is to tell a computer what to do!!

所以選擇對的工具比較重要！靈活的選對工具解決所面對的問題


專案流程的管理是重要的，但是只要有足夠的流程就好 (某種程度的Agile ?)

Process is important and Just enough process

不過Apache 的專案流程和管理模式真的是蠻值得參考的，分散式的協同合作，要如何動員遍佈世界各地的程式開發者，這充滿了智慧..... (按編：後面還會有其他講座在討論這些~)

還有對於系統的運作總是要保持著合理的懷疑，因為匯出問題的地方實在太多了，尤其是現在系統越來越複雜，Hole stack 從H/W-->F/W-->OS-->JVM-->APP….都可能出問題出bug


以上是小弟比較能理解的部份，其他有些部分我就比較沒辦法理解了~:P

延伸閱讀：

[1] Theo Schlossnagle To Keynote ApacheCon 2013

ApacheCon 2013 Hackathon 小體驗

以下是記者來自Portland ApacheCon Hackathon現場的報導 (事實上我只參加了上半場，然後就被時差擊沉了，想說中午去睡個午覺休息一下，醒來就已經是晚上6:00了... 囧rz...)


好~回到主題， 到底Hackathon是什麼呢？Hackathon 就像馬拉松一樣，一堆人在特定得時間聚集在一起，花較長的時間(例如一整天)，嘗試要達到某個目標，比如說之前參加過Facebook 的Hackthon 的活動，屬於比賽性質，目標就是大家在一定得時間內根據主辦單位提供的題目，開發出有趣的facebook app。

而Apache Hackthon 的目標呢？就是針對有報名的Project，大家聚集在一起一整天作以下的活動：

• Testing (面對面的幫忙測試找到問題)
• Bug Fixing (討論bug該如何解決)
• New Features (討論新的功能)
• Documentation (幫忙寫文件)
• Brainstorming (腦力激盪)
• Design and more!

主要是這些Open source 得專案成員都是散佈在全世界，平時都是靠IRC或是mail list在溝通，很多人甚至都沒見過面，因此趁這個機會大家聚在一起，可以面對面花較多時間溝通，討論一些事情，對於專案進展是很有幫助的。

那到底怎樣的人才有資格參加呢？

Everyone interested in getting involved in Apache Projects!
也就是有興趣的都可以來參加！

大會的流程是這樣，想參加的團隊會先跟大會報名，公布自己這個專案次次的目標，然後讓大家自由選擇，這次的題目有以下團隊：

Title	Open To	Description, Projects etc
Apache Traffic Server	Developers, users, newcomers	Testing, bug fixing, Lua plugin development, documentation
Apache HTTP Server	Developers, admins, newcomers	Bug fixing, General enhancement, mod_* development, documentation
Apache Cassandra	Developers and admin/users	Testing/bug squashing, CQL drivers, documentation
Apache Rave	Developers, users, newcomers	Adding Features, Bug Fixing, Documentation
Apache Branding	Anyone interested in brands/trademarks	Shane Curcuru, VP Brand Management for all Apache projects discusses trademarks
Apache CXF Fediz	Developers, newcomers	Brainstorming, Adding Features, Bug Fixing, Documentation
Apache Subversion	Developers, contributors of any kind	1.8 stabilization, local moves, anything else

到了現場每個桌子上都會有桌牌，寫著每一桌子的主題，每個人可以根據有興趣的題目到各組報到，不過很可惜的這些專案很多不是我沒聽過，不然就是沒啥興趣，所以來這邊晃晃，聽聽大家都怎麼討論後就閃人了~ (說實在真的是太累了....Orz...)

話說下面這張是2006年的照片，今年倒是都沒啥妹參加，也沒有這個制服可以拿~>////<

圖片來源：Ted Leung

Reference:
[1] ApacheCon North America 2013 Conference Hackathon

從Apache CloudStack Community 觀察社群運作原理，與提案的產生

Pic from：Microfactoria's blog

[此文同時分享於CloudStackTaiwan]

從上一篇文章 - "如何加入open source 社群" 發佈到現在已經一個多月了，每天的例行公事就是從上百封的mail list 中觀察社群的動向，並且找出有興趣，或是可以參與的主題，但是真的是很困難，很多議題不是插不上話，再不然就是發言沒人鳥(大概發言太廢~Orz..)，所以只能繼續做潛水觀察員。

而最近CloudStack 比較火熱的主題就是所謂Intellectual property clearance (A.K.A IP clearance) ，這個議題是從這篇討論開始 [ACS41] Concerns about where development has happened ，主要原因是因為Citrix 偷渡 貢獻了許多程式碼和new feature到 CloudStack 裡，因為這些 source code 與 new feature一來沒經過社群討論 (Mail List)，二來是從已經存在的產品Critrix Cloud Platform 拿出來的程式碼，所以可能會有 IP的問題，所以引發了社群的激烈討論，下面是其這個討論串發起人Chip Childers的描述：

I'm not sure where to go from here.  I guess we have 2 options: we
re-write the code from scratch as CloudStack code, or Citrix donates
the code produced for CloudPlatform (and it gets taken through the IP
clearance process).

而這一連串的討論， 也引發了其他人(新手小白如我)的緊張，到底怎樣的狀況需要IP Clearance，什麼樣的狀況需要宣告Donate source code? 於是就有人出來在這篇文章 "[PROPOSAL] Networking plugin to integrate the MidoNet SDN platform with CloudStack"解釋：

IP clearance is required only when your feature would have been developed outside the community intervention and you want to propose that feature to be merged with the asf/master branch.
(智財權釐清只有在你提供的新功能是在社群外開發才需要)

 If you have happened to discuss the functional spec for your feature with the community and answered the queries if any one might have in the community and done all your code commits through review requests , IP clearance would not be required at all .
(如果你的功能，是有充分在社群討論過，也被社群同意後才開始開發的，就不會有所謂智財權釐清問題，就算不是在所尾asf/master 開branch 開發也沒關係)

因為對於 Apache Community 一個新的提案產生正確的處理態度流程應該是這樣：

1. 在社群Mail List 提出Proposal
2. 在Mail list 被充分的討論後，並且交付表決，是否同意納入這個功能
3. 如果同意後，到Apache cloudstack 的 wiki 撰寫你的 Proposal 與 Spec
4. 開發，並且交由commiter review

參考範例：
Mail List ：[DISCUSS] PaaS Enablement: Composite Application Blueprints
提案wiki：Feature Proposal -- Composite Application Blueprints

延伸閱讀：
[1] Open source participation - Remixing Angie Byron to create the next Million Mozillians
[2] Open Source Communities and Customers in Pictures

如何加入open source 社群

Source: Photograph by Nicole C. Engard

人生就是不斷的在挑戰啊，以前可以裝弱(其實真的很弱不用裝)，裝公司小沒資源、沒有時間，但是現在沒有藉口了，因為大老闆希望我們能加入Cloudstack的社群，成為contributor，甚至成為commiter，這下我可頭大了！！一堆問題馬上產生，如何加入？如何成為contribotor？如何成為commiter？審核機制是什麼？  

要了解這些東西，就得先從歷史開始了解，話說cloudstack 有著一段複雜的歷史背景，他一開始是cloud.com這家公司所獨立開發得產品，但是後來cloud.com被Citrix買下來，不過基於戰略考量，Citrix 又把 cloudstack open source出來捐給apache基金會，但是不是捐出來就沒事了，必須先經過好幾個階段，第一個階段就是送審查想辦法進入incubator的專案，流程如下圖所示：

 Source: Apache Incubator Process_Description

也就是要完成幾項任務：

1. 任何一個孵化器的項目， 都要在Apache中找到一個實體作為自己的Sponsor， 這個 Sponsor可以是一個具體的Apache Top-Level-Project (TLP)，或者是找Apache Incubator 的 PMC (Project Management Committee)也可以作為Sponsor Sponsor會選擇合適的人選（一般三個）作為孵化器中專案的mentor， mentor必須都是Apache Incubator PMC member， mentor負責指導孵化器中專案， 確保孵化器中專案按照Apache的方式運行， 直至順利畢業。
2. 而任何進入孵化器的項目都可以指定一批committer， 這些committer被稱之為該項目的initial committer，所以citrix 想當然耳就是cloudstack的 initial commiter，畢竟一開始就這些人最熟了。

在進入incubator的狀態後，還必須達到幾項KPI才能轉成正式的專案(畢業)，所謂的 Top-Level-Project (TLP)，這些指標分別是：

1. 完成Check List 上面的交辦事項
2. Ensure suitable project name and product names
3. Creating an Apache Release - Release Early, Release Often  Eric Steven Raymond
4. Creating an Open and Diverse community (這是最重要的)
1. Recruit users, developers, committers and PMCers 
2. Take responsible collective action 
3. Disagree in public on technical matters without destroying personal relationship
4. Create an open, positive and inclusive atmosphere on the mailing lists

其他詳情請參考：Guide to Successful Graduation

其中第四點是最重要的，社群必須要活絡(由 mail list上的討論情況就可以知道)，貢獻者除了數量要多外，也必須要多樣化(不能只是少數公司把持)

所以老大希望我們加入的原因，應該是一來希望能加速這個社群的蓬勃發展，早日變成TLP，二來也可以增加對cloudstack發展的影響力。

由於北京有些同事已經是commiter了，所以之前有跟他們交流該怎樣參與比較容易成為commiter，他給我幾個建議

• 追蹤 mail list 和 IRC channel 
• 了解community 目前正在討論什麼，想要解決什麼問題
• 參與討論，幫忙回答問題
• 幫忙測試，回報bug
• submit patch
• fixing bug
• 幫忙整理文件或是wiki  

最後才有機會成為 commiter 可以負責commit code，但是光是第一點我就快招架不著了，Mail list的討論串非常的混亂，而且每天有好幾百封的討論，真的很難插入話題。
而且我現在遇到一個很奇怪的問題，就是大家在mail list討論所顯示的名稱都是全名，比如說Erice Steve，但是只有我的是顯示完整的emial，整個感覺很怪也格格不入，不知道有沒有open source 界的大大願意指點一下。

Source: itnservice

吃了Apache Open soruce 專案那麼多年奶水，希望將來真的能有所貢獻回饋社群啊~~所以現在只能看看有沒有機會找到些bug來幫忙fix....Orz..


延伸閱讀：
[1] 什么是Apache Incubator 以及 Apache CXF的前世今生