From takebayashi.shinya ＠ oss.ntt.co.jp Wed Jan 26 08:22:29 2011 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Wed, 26 Jan 2011 08:22:29 +0900 Subject: [Ultramonkey-l7-develop 660] Re: =?iso-2022-jp?b?djMbJEIkThsoQkw3ZGlyZWN0b3JkKFJBKRskQj0kGyhC?= =?iso-2022-jp?b?GyRCQDUkSCEiPSRANUhHJE4laiVqITwlOSRLJEQkJCRGGyhC?= In-Reply-To: <4D3EA42D.30808@nttcom.co.jp> References: <4D355B0C.1010503@nttcom.co.jp> <4D3D3DA0.7020006@nttcom.co.jp> <4D3EA42D.30808@nttcom.co.jp> Message-ID: 雲雀 さま 竹林です． おつかれさまです． > ブランチ作成の件、承知いたしました。 > ひとまず3.0.1を公開した時点で、タグ打ちとブランチの作成を > 行おうと思います。 もう master ブランチに変更が入ってしまっているので 3.0.0 リリースのタグ付けは間に合いませんから，3.0.1 公開時にタグを 打ってください． ブランチの作成ですが，リリース段階では不要です． バグ修正などで master ブランチに変更を加えようとしたときに， master からブランチを作成して修正してください． この辺りは git に限らず RCS 共通で言えることなので， 適宜本を読むなりして勉強してみてください． 以下，一般的なやり方です． 今回のように RA の修正が発生した場合は 1. master から RA 修正用のブランチを作成する git branch -c modify_ra origin/master 2. modify_ra ブランチに対して変更を加え，コミット，push する git push origin modify_ra:modify_ra 3. リリース準備用のブランチを作成する git branch -c rc_301 origin/master 4. 3.0.1 リリースに含めるブランチの修正をマージする git merge origin/modify_ra 5. アーカイブを作成する git archive --format=tar --prefix=ultramonkeyl7-3.0.1/ rc_301 | gzip > ultramonkeyl7-3.0.1.tar.gz 6. テストするし，問題なければリリースする 7. master ブランチに rc_301 ブランチをマージする git checkout master git merge rc_301 git push origin master:master 8. リリースタグを打ち，push する． git tag 3.0.1_release git push --tags 9. 不要なブランチを削除する git push origin :modify_ra git push origin :rc_301 ← 削除しなくても良いかも ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- From sugiura.jun ＠ oss.ntt.co.jp Wed Jan 26 10:51:15 2011 From: sugiura.jun ＠ oss.ntt.co.jp (Jun Sugiura) Date: Wed, 26 Jan 2011 10:51:15 +0900 Subject: [Ultramonkey-l7-develop 662] =?iso-2022-jp?b?djMgbDdkaXJlY3RvcmQubG9nGyRCJE4lbSUwJWwlWSVrGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= Message-ID: <20110126101927.E77C.9A97E586@oss.ntt.co.jp> 杉浦です。 l7directord.logへのログ出力レベルに関して 現在以下のようなものがあるのですが、 [Fri Jan 21 20:14:11 2011|7221] [WRN0203] Service check OK. HTTP response is valid. HTTP response status line is `200 OK' (real - `192.168.10.11:80') [Fri Jan 21 20:14:11 2011|7221] [ERR0601] Service up detected. (Real server `192.168.10.11:80') 正常動作が[WRN]だったり[ERR]だったりするのは妙なので 上記については[INF]にした方が良いと思いますがどうでしょうか。 （他にも類似の箇所があれば合わせて） 以上、ご確認ください。 -- Jun Sugiura From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Jan 26 11:00:03 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 26 Jan 2011 11:00:03 +0900 (JST) Subject: [Ultramonkey-l7-develop 663] Re: =?iso-2022-jp?b?djMbJEIkThsoQkw3ZGlyZWN0b3JkKFJBKRskQj0kGyhC?= =?iso-2022-jp?b?GyRCQDUkSCEiPSRANUhHJE4laiVqITwlOSRLJEQkJCRGGyhC?= In-Reply-To: References: <4D3EA42D.30808@nttcom.co.jp> Message-ID: <20110126.110003.2083037958085180882.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 コメントします。 Shinya TAKEBAYASHI -san wrote: >> ブランチ作成の件、承知いたしました。 >> ひとまず3.0.1を公開した時点で、タグ打ちとブランチの作成を >> 行おうと思います。 > > もう master ブランチに変更が入ってしまっているので > 3.0.0 リリースのタグ付けは間に合いませんから，3.0.1 公開時にタグを > 打ってください． タグづけはコミットを指定してやれば、過去のどの時点に対しても 可能です。 # git tag -a v3.0.0 1c69 とか。 あと、正式なリリースのタグをつけるときは git tag -a でアノテーションタグをつけた方がよいと思います。 普通のタグはコミットオブジェクトの単なる別名ですが、アノテー ションタグはDate, Author, タグメッセージ、コミットオブジェク トを含んだタグが作成されます。つまり、いつ誰がどういう理由で つけたのか残せます。 git describe などの挙動にもアノテーションタグかただのタグかが 影響しますし。 > > ブランチの作成ですが，リリース段階では不要です． > バグ修正などで master ブランチに変更を加えようとしたときに， > master からブランチを作成して修正してください． リリース用ブランチというか、統合用ブランチですが、バグフィク ス系と新機能追加系の統合用ブランチを切っておくのが楽だと思い ます。v2 リポジトリでは maint と master がこれにあたります。 (その後masterからリリースしてないですし、過去のリリースから直 接生やしたブランチから緊急のリリースがあったので大分カオスな 状況ですが・・・) 新規機能統合用として master ではなく devel などをつくっておい て、リリース後に master へマージ(というかdevel上のリリースの コミットへmasterをfast-forward)というのもありだと思います(竹 林さんの言ってるのはこういうことだと思います) リリースした場合のみmasterにマージする利点は master をチェッ クアウトしたときにいつでもリリース版がチェックアウトされるこ とです。 > > この辺りは git に限らず RCS 共通で言えることなので， > 適宜本を読むなりして勉強してみてください． > > 以下，一般的なやり方です． > 今回のように RA の修正が発生した場合は > > 1. master から RA 修正用のブランチを作成する > > git branch -c modify_ra origin/master branch -c はたぶん checkout -b のことですね。 -- TATEISHI Katsuyuki From sugiura.jun ＠ oss.ntt.co.jp Wed Jan 26 11:22:25 2011 From: sugiura.jun ＠ oss.ntt.co.jp (Jun Sugiura) Date: Wed, 26 Jan 2011 11:22:25 +0900 Subject: [Ultramonkey-l7-develop 664] =?iso-2022-jp?b?djMgGyRCPEIlNSE8JVA0RjtrIUolXSE8JUgbKEIr?= =?iso-2022-jp?b?GyRCJTUhPCVTJTkhSyRLJEQkJCRGGyhC?= Message-ID: <20110126110311.E77E.9A97E586@oss.ntt.co.jp> 杉浦です。 実サーバ監視についてです。 checktype を数値（サービス監視+ポート監視）とした際に 「サービス監視」に失敗して振り分け先サーバから切り離した後 「ポート監視」に成功すると振り分け先サーバとして組み込むという という動きをするのですが、 「サービス監視」に失敗した場合は「サービス監視」が成功するまで 振り分け先サーバとして組み込まないというのが望ましい動作だと 思いますので （１）「サービス監視」に失敗した場合は「ポート監視」が成功しても無視して 　　　次に「サービス監視」が成功した時点で振り分け先サーバとして組み込む （２）「サービス監視」に失敗した場合は「ポート監視」を行わず 　　　「サービス監視」が成功するまで「サービス監視」のみを続ける のどちらかにした方が良いと思いますがどうでしょうか。 以上、ご確認ください。 -- Jun Sugiura From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Jan 26 11:42:01 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 26 Jan 2011 11:42:01 +0900 (JST) Subject: [Ultramonkey-l7-develop 665] Re: =?iso-2022-jp?b?djMgGyRCPEIlNSE8JVA0RjtrIUolXSE8JUgbKEIr?= =?iso-2022-jp?b?GyRCJTUhPCVTJTkhSyRLJEQkJCRGGyhC?= In-Reply-To: <20110126110311.E77E.9A97E586@oss.ntt.co.jp> References: <20110126110311.E77E.9A97E586@oss.ntt.co.jp> Message-ID: <20110126.114201.161527626946871721.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 Jun Sugiura -san wrote: > （２）「サービス監視」に失敗した場合は「ポート監視」を行わず > 　　　「サービス監視」が成功するまで「サービス監視」のみを続ける がいいと思います。 ちなみに元になったと思われる ldirectord(not l7directord)をざっ と見たところ、(2)的な仕様のようです。 -- TATEISHI Katsuyuki From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Jan 26 16:55:15 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 26 Jan 2011 16:55:15 +0900 (JST) Subject: [Ultramonkey-l7-develop 666] Re: =?iso-2022-jp?b?GyRCO0QlQSUxJUMlSCRLJEQkJCRGGyhC?= In-Reply-To: <4D3EB644.2040300@oss.ntt.co.jp> References: <4D3EB644.2040300@oss.ntt.co.jp> Message-ID: <20110126.165515.772628696511515614.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 チェックありがとうございます。 morisita -san wrote: > 19261　l7vsadm の無駄なタイムアウト待ちを修正する > 　→3.0.0ではinit.d/l7vsdの対処なし。con_interval, con_count廃止済み。 > 　　2.1.3-1ではinit.d/l7vsdの対処なし。con_interval, con_count未廃止。 > 　　（修正されていない？） 2.1.3-1についての認識はあっています。 3.0.0 の状況については把握していませんでしたが、そうなってい ると思われる事象が発生していますので、上記のとおりかと。 詳しくは杉浦さんからレポートがあると思いますが、l7directord が l7vsdが上がりきっていないうちに起動して l7vsadm を発行し、 エラーが記録されている、というものです。 ** 以前杉浦さんが2.1系で判明している不具合についてまとめてくれ ていましたが、あれも登録したほうがよさそうですね・・・ -- TATEISHI Katsuyuki