Fluentd v11 なんてなかったんだ

Sadayuki Furuhashi @frsyuki

@repeatedly @tagomoris @kiyototamura たとえば @taroleo さんをオフィスに呼んで（笑）、適当なお題をfluentdで設定してもらって、「あ、ココ分かりにくくてヤバいな」みたいなのを後ろから観察する…とか？

Sadayuki Furuhashi @frsyuki

@repeatedly @tagomoris @kiyototamura 初心者ユーザーは貢献するモチベーションも小さいと思うので、どこかで自分がえいやっと決める必要があるとは思います。

tagomoris @tagomoris

@kiyototamura @frsyuki @repeatedly まあ超ぶっちゃけると「v11なんてなかったんだ、v10を1.0にしてそのまま改良していこう」という線もありだとは思います。細かい非互換性をどこかで少しずつ作りながら改良していくことにはなるでしょうが。

Kiyoto Tamura @kiyototamura

@frsyuki @repeatedly まあ特筆すべきものはないというのは語弊があるな。どちらかというと「パッとみて分りやすい差別化機能」みたいのがないのかもしれない。これはマーケの問題でもあるのだろうけど。

tagomoris @tagomoris

@taroleo @frsyuki @kiyototamura @repeatedly それはどっちかというと頻出パターン集みたいなのをさっさとドキュメントサイトに作ろうぜ！ みたいな話？

Sadayuki Furuhashi @frsyuki

@kiyototamura これはナイスなフィードバックですね：https://t.co/8ZMhwkbS2f

SKS rep @repeatedly

@tagomoris @frsyuki @kiyototamura 実はv10を1にする案はあります．いくつか機能提案を後でissueでしますが

Kiyoto Tamura @kiyototamura

@frsyuki @repeatedly たとえばworker機能が入りましたといっても一見さんには通じない。CPUをもっと効率的に使えますみたいに言えば、それは響くと思う。v11のメリットみたいのを、初心者にも分りやすく書き下す必要があるのかも。

Sadayuki Furuhashi @frsyuki

@tagomoris @repeatedly v10を1.0にするのもアリだと思います。少しずつ改善していく形は無理がない。例えばエラーストリームは、Engine部分の差し替えで実現できる。

Sadayuki Furuhashi @frsyuki

@tagomoris @repeatedly Actor&SocketManager導入もできると思います。ただlabelとかはフィルタプラグインは、プラグインAPIを変えないと行けない。Engine.emitがグローバルなメソッドなので困る。

tagomoris @tagomoris

@__yuunyan__ オススメの順に 1. 汎用性がありそうな改良なら既存プラグインにpullreq 2. 既存プラグインをforkしてprivate gem化 or fluentd -p で .rb を読み込み ですね

SKS rep @repeatedly

v11が登場した当時は，まだ今ほどプラグインもなくて，半分以上がモリスさんとかyoshi_kenさんで埋められていたのでえいやと互換性を導入すればいいやという話だったんだけど，今だともう少し違うアプローチがある気はする

tagomoris @tagomoris

@frsyuki @repeatedly Engine 自体を互換性レイヤをもった何かに差し替える、とかはできるんじゃないかなー。どうすかね。

Sadayuki Furuhashi @frsyuki

@tagomoris @repeatedly Engineを差し替えるのは普通にできて、エラーストリームとか入れられると思います。あとフィルタプラグイン（ネストしたmatch）は、Configurableにユーティリティメソッド追加する形でできるかも。

SKS rep @repeatedly

log_level機能をv10に実装することで，グローバルな状態に依存したAPIをメソッドに置き換える負荷を計る，とか

Sadayuki Furuhashi @frsyuki

@frsyuki ここで言っているのは、フィルタプラグインは自分がフィルタプラグインであることが分かっているはずなので（当然）、フィルタプラグインだけはEngine.emitは使えなくて event_router.emitを使ってね、ということにできるということ

Sadayuki Furuhashi @frsyuki

@repeatedly それはナイス。v11に移行しよう！じゃなくて、$logはやめてlog_levelを使えるようにしよう！という細かい問題にするわけですよね。ナイスアイディア。

SKS rep @repeatedly

@frsyuki log_levelを指定した時に，Fluentdがそれを実装しているかどうかチェックすればいいので，既存プラグインはそのまま$logを使い続けられるし，Engine.emit周りも同じ方法で移行は出来る気がしている

SKS rep @repeatedly

プラグイン作る人はちょっとマイナーバージョンを上げる必要があるけど，まぁEngine.emit周りと$log周りの変更であれば，まぁ多少は大丈夫な気がする．

Sadayuki Furuhashi @frsyuki

@repeatedly $logが使い続けられるのは良いですね。Engine.emitも実は、指定されたlabelに直接emitしたいinputプラグインか、ネストした<match>を持つフィルタ系outputプラグインにのみ必要なので、

Sadayuki Furuhashi @frsyuki

@repeatedly そういうプラグインを書きたい人は新API使ってね！ってことですよね。良いアイディアだと思います。to_labelオプションをサポートするためのMixinモジュールとか用意しても良いかもです。

SKS rep @repeatedly

@frsyuki yes．td-agentは基本的に新しめのfluentdを使うので，td-agent使っているユーザは基本的に問題ないはず

Sadayuki Furuhashi @frsyuki

@repeatedly マイナーバージョン上げるのと、fluentdの依存バージョンをgemspecで上げる必要がありますね。それくらいはやってもらえるでしょう。

SKS rep @repeatedly

ちょっとv11の機能のいくつかをv10にマージするプランを考えよう

SKS rep @repeatedly

いくつかをマージしたらv1にしてリリースしたい