OSSプロダクトにissue登録する

僕は今見ている社内のログ分析基盤に数多くのOSSプロダクトを使っています。

具体的に言うと、Fluentdでログ収集してHadoopに書き込んでAzkaban経由でHiveバッチを動かしてデータを加工してPresto, Prestogres経由でみたりしています。

また最近はKafkaやElasticsearch, Kibanaといったものも使っていますし、Prometheus, Grafanaを使ってモニタリングするようになっています。

このように数多くのOSSプロダクトを使っている理由は、部品一つ一つを自前実装していたら時間がいくらあっても足りないからです。OSSプロダクトを活用することにより、レバレッジを効かせることができます。

そしてまたOSS界隈の進化のスピードが速いので、仮に自前実装したとしてもすぐに陳腐化してしまう危険性がある。であれば最初からOSSプロダクトを使って巨人の肩に乗るのが望ましいです。

しかしどのOSSプロダクトを選ぶかは重要です。将来を予測するのは困難ですが、開発が活発なものを選ぶべきです。そしてそのOSSプロダクトがどういうユースケースを第一に考えているのかを感じ取るのも重要です。なぜならそのOSSプロダクトが想定していないユースケースで使うと、バグに遭遇しても対応してくれない危険性があるからです。

例えばPrestoがJDBCにイマイチ乗り気でなかったのはおそらくFacebookがHiveを前提にしていたからだと思います。ただこれも改善されそうで何よりです。

このように数多くのOSSプロダクトを使っていると、バグに遭遇することもあります。

その場合、Twitterにつぶやいただけだとすぐ流れてしまって良くないので最近はissue登録するようにしています。すでに登録されていたら俺も遭遇したよってコメントしてます。
簡単に直せそうだったらPull Requestしてもいいんですが、そういうのはそんなに多くないですし、まずはissue登録するのが良いと思います。

僕の場合の具体例はこの辺
https://issues.apache.org/jira/browse/AMBARI-15418
https://issues.apache.org/jira/browse/HIVE-13374
https://github.com/prestodb/presto/issues/5353
https://github.com/grafana/grafana/issues/5165

自分と同じ問題に遭遇して俺も遭遇したよって言った例は下記
https://github.com/kazegusuri/fluent-plugin-prometheus/issues/2
https://github.com/elastic/elasticsearch/issues/18635

もちろんissue報告したからといってすぐ対応されるわけじゃないですが、何もしないよりは作者に伝わって良いと思います。それに自分と同じ問題に遭遇している人がもしいたら参考になると思いますし。

それに勢いのあるOSSプロダクトだとすぐ直ってリリースされるので効率がいいです。以前は諦めてその後何もしなかったけど、なんかしら報告しといたほうが残るので良いと思います。

とはいえ雑なissue登録しても迷惑なだけなので、もしissue templateがあればそれに従いましょう。無くても環境だったり設定だったりログだったりをちゃんと書きましょう。ただしパスワードなどの機密情報をうっかり書かないようにちゃんとマスクしましょう。

僕の考え方としてforkして独自パッチというのは原則として考えてないです。そういうケースもありますけど、なるべく避ける。理由はバージョンアップについていくのが辛いから。ただ開発が止まっているプロダクトならありかも。

それに使っているOSSプロダクトのパッチを書くのは本来の仕事じゃないよなとちょっと思っているし、微妙なパッチを送るよりかは専門家に任せたいなあと。もちろん放置されてたら別ですけど。

まあ、そんな感じです。以前も似たようなこと書いてた。
OSSプロダクトとのつきあい方 - wyukawa’s blog