気がついたら Apache Hadoop 2.9.2 の release manager になってしまい、色々あったものの無事リリースを終えることができたので、感想や知見などをまとめておきます。Hadoop の機能の話は一切ありません。期待した人はごめんなさい。
release managerになるまで
まずは、どういったきっかけで私が release manager になったのかを書いていきます。
Apache Hadoopのリリースに関するおさらい
前提として、Hadoop のバージョンはx.y.z表記で、xがメジャー、yがマイナー、zがバグフィックスです。
一般にリリースは頻繁なほどよいのですが、あまり理想通りにはいきません。なぜならリリースは面倒だからです。それでも2014年頃には、四半期に1回くらいマイナーバージョンを出していくのがいいだろうという話があり、実際にそれくらいのハイペースでリリースされていました。過去のリリース履歴 によると、
- 2.3.0: 2014/02/20
- 2.4.0: 2014/04/07
- 2.5.0: 2014/08/11
- 2.6.0: 2014/11/18
という感じでした。直近だと、
- 3.0.0: 2017/12/13
- 3.1.0: 2018/04/06
- 3.2.0: もうすぐリリース
なので、少し頻度が減ってきたかなと思います。しかしながら、メンテナンスされる branch の増加に伴い bug fix release の数が増えていて、現在、実は1ヵ月に1回くらいは何かしらのリリースが発生しています。この記事を書いている現在では、2.7, 2.8, 2.9, 3.0, 3.1系がメンテナンスされています。2.3 から 2.5 の頃はあまりコミュニティでメンテナンスされておらず、 bug fix release も 2.5.2 程度で止まっていましたが、2.6 あたりからメンテナンスリリースをまともにやるようになっていて、2.7系に至っては 2.7.7 まで出ています。現在も branch-2.7 がメンテナンスされているため、2.7.8 もいずれリリースされると思います。
- (参考) 2.6.1 をリリースしたいと言って、release manager のお手伝いをしたときの話: https://www.slideshare.net/hadoopxnttdata/hadoopmaintainance-release-nttdata
メンテナンスされるbranchの増加と、それによる脆弱性対応の難しさ
ソフトウェアには脆弱性がつきもので、Apache Hadoopであっても、時々脆弱性が見つかります。すると、Hadoopのコミッタが購読している private なメーリングリストで共有・修正され、CVE (Common Vulnerability and Exposures)が必要だと判断されれば CVE をつけて公表されます。
- ASF(Apache Software Foundation)における脆弱性対応の方法: https://www.apache.org/security/committers.html#vulnerability-handling
- Apache HadoopのCVE一覧(cvedetail): https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-22215/Apache-Hadoop.html
- Apache HadoopのCVE一覧(公式、新しいもののみ): https://hadoop.apache.org/cve_list.html
ここで、脆弱性を公表する前には、脆弱性が修正されたリリースを出す必要があります。これは当たり前ですね。しかしながら、これを少し言い換えると、脆弱性に当てはまる branch でメンテナンスされているものは全てリリースしなければならない、ということになり、メンテナンスしている branch の数が増えれば増えるほど大変になります。脆弱性の公表をしなければならないのに、そのためには x.y.z のリリースをしないといけない、というようなことがたびたび起こります。
今回についても、2.9.2 がリリースされないせいで公表できない CVE があったので、自ら release manager となって Apache Hadoop 2.9.2 をリリースすることを決意しました。
release managerになるには
Apache Hadoop のコミッタであることが必要条件で、他に条件はありません。リリース時に release artifact を実際に配置するところだけは、PMC(Project Management Committee) の権限が必要なので、そこだけ PMC に手伝ってもらえばよいです。
あとは、release manager をやりたいと名乗り出るだけです。
- bug fix release の場合、直前のリリースを担当した人にモチベーションがあれば、その人にやってもらうのが楽でしょう
- major/minor release の release manager をやりたがる人は沢山いるので、その人達に任せましょう
release managerの作業
ここから先は公式のHowToReleaseに従っていくだけです。しかしながら、実際にやってみると結構泥臭かったので、以下ではその泥臭い部分を掘り下げていきます。
release candidate作成まで
-
2.9.2 に backport されるべき bug fix がないか確認する
-
target versions に 2.9.2 がセットされているがクローズされていない JIRA をリストアップし、重要なものはクローズさせ、そうでないものは 2.9.2 から外す
- YARN-8233 をなんとかクローズさせました
- これをやっている間になぜかJenkinsで実行されるJUnitのテストが全て失敗するという事象にハマり、原因を特定して直しました。(HADOOP-15916)
- Javaのバージョンが上がったのが原因だった...
-
コミットログと JIRA のデータで整合性が取れているか確認する
- Apache Hadoop の Changelog および Release Notes は JIRAのデータから Apache Yetus の releasedocmaker によって自動生成される
- JIRA の情報が間違っていると間違ったリリースノートが作成されてしまう
- そのため、ログを突合させて、JIRA の編集し忘れやコミット忘れをチェックする
- 5件くらい JIRA を直しました
- これはシステマチックにしたい
release candidate作成、voting
ドキュメントには以下のコマンドを叩くだけと書いてありました。
$ dev-support/bin/create-release --asfrelease --docker --dockercache
上記のスクリプトでは、Docker containerが起動して
- binary tarballの作成
- changelog/release note の作成
- gpg sign
といったことを全てやってくれます。しかし、2時間くらい経過した後に maven-gpg-plugin で落ちました。しかも、何度試してもだめなので、何かを修正する必要がありました。これについては、原因がわかればなんてことないのですが、以下の理由で苦労しました:
- 再現させるのに2時間以上かかる
- 毎回 clean build するからとても遅い
- クラウド環境が使えない
- GPG private key を安全に管理できないため: http://www.apache.org/legal/release-policy.html#owned-controlled-hardware
- 家で私物PCを使って毎晩回す羽目に
- 結果がわかるのが翌朝、もしくは深夜に起きて確認
原因は、gpg-agent の設定:
-
HADOOP-13996 で
default-cache-ttlは4時間に設定されていた -
max-cache-ttlはデフォルトの2時間のままだった - 2時間を超えると
max-cache-ttlのほうが作用して、キャッシュの効果が消える - HADOOP-15923 で修正した
誰もビルドに2時間以上かからなかったんだろうなぁ... 考えられる原因は以下の通り:
- 私物PC(MBP 15inch (2016))のスペック不足
- Docker for Macのチューニング不足
- これまでの release manager はほぼ全て US在住なので、依存関係のあるライブラリのダウンロードで海を跨ぐことがなかった
他には、 git tag を push しようとして、あろうことか git push --tags と叩いてしまい、ローカルにある tag を全て push してしまうというオペミスをしてしまいました。消せるものはすぐに消しましたが、 ASF 側の設定で rel/ から始まる tag は protectされていたので、ASF の INFRA team に消してもらいました (INFRA-17248)
-
やらかしても謝ればすむのがいいところです
-
失敗は完全に明るみにして、再発を防ぐというねらいもあります
- 同じ Apache Hadoop 開発者の失敗談として好きな記事です: http://steveloughran.blogspot.com/2017/10/roca-breaks-my-commit-process.html
- 一言で言うと「使わなくなった古いGPG鍵は revoke ではなくて expire させるべし」というもの
その他の作業では、特にハマることはありませんでした:
- Maven staging repository に登録するのは初めてで緊張しましたが、手順通りにやるだけでした
- Voteではメールを書くことになりますが、大した作業ではありません
リリース作業
無事 vote が通りましたが、 release manager がリリース作業をするまでそのリリースが世にでることはありません。最後の踏ん張りどころです。
ここでは、 distribution directory (リリースのミラー元)に svn commit するところで、ファイルサイズの制限にハマりました。ただし、これは既にハマった人がいることがわかり、そこに解決策も書いてあった
commit your files to dist/dev then svn mv. This should be part of your documented release process.
のでなんとかなりました。なぜかHowToRelease のドキュメントに反映されていなかったので、修正しておきました。
release artifact が mirrorsite に伝搬するまでに時間がかかるので、1日経ってからアナウンスしました。
リリース後の作業
2.9.2 のリリースができたので、ようやく脆弱性を公表するための準備が整いました。とはいえ、これも以下の手順に沿ってやるだけです:
今回の場合だと、 CVE-2018-8009 の詳細版 を公表することができました。
- これは脆弱性の修正者も(半分は)自分なので、感慨深いです
感想および今後の展望
7年ほど前に初めてApache Hadoopに触っていた頃の自分に「お前は将来 Hadoop の release manager をやっているぞ」、と言われても信じなかったと思います。まさかこんなことをやることになるとは思いませんでした。Release manager も体験したし、あとは PMC Chair (雑に言うとプロジェクトのリーダ) ですかね。いや、それはさすがにないか...