Apache Hadoop 2.9.2 をリリースした話

気がついたら Apache Hadoop 2.9.2 の release manager になってしまい、色々あったものの無事リリースを終えることができたので、感想や知見などをまとめておきます。Hadoop の機能の話は一切ありません。期待した人はごめんなさい。

# release managerになるまで

まずは、どういったきっかけで私が release manager になったのかを書いていきます。

## Apache Hadoopのリリースに関するおさらい

前提として、Hadoop のバージョンは`x.y.z`表記で、`x`がメジャー、`y`がマイナー、`z`がバグフィックスです。

一般にリリースは頻繁なほどよいのですが、あまり理想通りにはいきません。なぜならリリースは面倒だからです。それでも2014年頃には、四半期に1回くらいマイナーバージョンを出していくのがいいだろうという話があり、実際にそれくらいのハイペースでリリースされていました。[過去のリリース履歴](https://hadoop.apache.org/old/releases.html) によると、

* 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](https://wiki.apache.org/hadoop/HowToRelease)に従っていくだけです。しかしながら、実際にやってみると結構泥臭かったので、以下ではその泥臭い部分を掘り下げていきます。

## release candidate作成まで

* 2.9.2 に backport されるべき bug fix がないか確認する

  * branch-2 に入っているが branch-2.9 に入っていない blocker/critical bug を[リストアップ](https://s.apache.org/2.9-candidate-jiras)し、必要そうなものを backport する
  * これで2件backportしました ([YARN-7765](https://jira.apache.org/jira/browse/YARN-7765), [YARN-8404](https://jira.apache.org/jira/browse/YARN-8404))

* target versions に 2.9.2 がセットされているがクローズされていない JIRA を[リストアップ](https://s.apache.org/2.9.2-targeted-jiras)し、重要なものはクローズさせ、そうでないものは 2.9.2 から外す

  * [YARN-8233](https://jira.apache.org/jira/browse/YARN-8233) をなんとかクローズさせました
  * これをやっている間になぜかJenkinsで実行されるJUnitのテストが全て失敗するという事象にハマり、原因を特定して直しました。([HADOOP-15916](https://jira.apache.org/jira/browse/HADOOP-15916))
    * Javaのバージョンが上がったのが原因だった...

* コミットログと JIRA のデータで整合性が取れているか確認する

  * Apache Hadoop の [Changelog](https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoop-common/release/2.9.2/CHANGES.2.9.2.html) および [Release Notes](https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoop-common/release/2.9.2/RELEASENOTES.2.9.2.html) は JIRAのデータから Apache Yetus の [releasedocmaker](https://yetus.apache.org/documentation/in-progress/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](https://issues.apache.org/jira/browse/HADOOP-13996) で `default-cache-ttl` は4時間に設定されていた 
* `max-cache-ttl` はデフォルトの2時間のままだった
* 2時間を超えると `max-cache-ttl` のほうが作用して、キャッシュの効果が消える
* [HADOOP-15923](https://issues.apache.org/jira/browse/HADOOP-15923) で修正した

誰もビルドに2時間以上かからなかったんだろうなぁ... 考えられる原因は以下の通り:

* 私物PC(MBP 15inch (2016))のスペック不足
* Docker for Macのチューニング不足
* これまでの release manager はほぼ全て US在住なので、依存関係のあるライブラリのダウンロードで海を跨ぐことがなかった

他には、 git tag を push しようとして、あろうことか `git push --tags` と叩いてしまい、ローカルにある tag を全て push してしまうという[オペミスをしてしまいました](https://lists.apache.org/thread.html/345893eb4af0facccf0fdf62d7283c41ce62facc3a1ce80bf2ad02d0@%3Ccommon-commits.hadoop.apache.org%3E)。消せるものはすぐに消しましたが、 ASF 側の設定で `rel/` から始まる tag は protectされていたので、ASF の INFRA team に消してもらいました ([INFRA-17248](https://issues.apache.org/jira/browse/INFRA-17248))

* やらかしても謝ればすむのがいいところです

  * [謝罪メール](https://lists.apache.org/thread.html/be03a5caf7f2ae42e3974f25edbe89c82a0fbaccc401da723a411787@%3Ccommon-dev.hadoop.apache.org%3E)

* 失敗は完全に明るみにして、再発を防ぐというねらいもあります

  * 同じ 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` するところで、ファイルサイズの制限にハマりました。ただし、これは既に[ハマった人がいることがわかり](https://issues.apache.org/jira/browse/INFRA-16518)、そこに解決策も書いてあった

> commit your files to dist/dev then svn mv. This should be part of your documented release process. 

のでなんとかなりました。なぜかHowToRelease のドキュメントに反映されていなかったので、[修正しておきました](https://wiki.apache.org/hadoop/HowToRelease?action=diff&rev2=100&rev1=99)。

release artifact が mirrorsite に伝搬するまでに時間がかかるので、1日経ってから[アナウンスしました](https://lists.apache.org/thread.html/e6e822303378a8f9471ea78e6443ae30d1058da80680811b97393537@%3Cgeneral.hadoop.apache.org%3E)。

## リリース後の作業

2.9.2 のリリースができたので、ようやく脆弱性を公表するための準備が整いました。とはいえ、これも以下の手順に沿ってやるだけです:

* https://www.apache.org/security/committers.html#vulnerability-handling

今回の場合だと、 [CVE-2018-8009 の詳細版](https://lists.apache.org/thread.html/805459160bafe569fb479be3b12012aad224d11f56cf156f80594edd@%3Cgeneral.hadoop.apache.org%3E) を公表することができました。

* これは脆弱性の修正者も(半分は)自分なので、感慨深いです

# 感想および今後の展望

7年ほど前に初めてApache Hadoopに触っていた頃の自分に「お前は将来 Hadoop の release manager をやっているぞ」、と言われても信じなかったと思います。まさかこんなことをやることになるとは思いませんでした。Release manager も体験したし、あとは PMC Chair (雑に言うとプロジェクトのリーダ) ですかね。いや、それはさすがにないか...