2009年12月01日第7回開発会議

[石川雅彦]

石川@とりまとめ担当です。

以下の要領で開発会議を開催します。よろしくお願いします。
会議資料はこのトピックへの返信として添付していただけるとありがたいです。
よろしくお願いします。
--------------------------------------------------------------------------------
■日時:2009年12月 1日(火) 14:00(午後2時) -
■場所: 名古屋大学情報基盤センター 4F 会議室 (演習室とは異なる部屋です)
交通: 名古屋市営地下鉄 名城線 名古屋大学駅 下車 2番出口
http://www.nagoya-u.ac.jp/global-info/a ... gashiyama/ の 56番の建物

--------------------------------------------------------------------------------
■議題(予定)
1. NGMS Phase1 リリースチェック
(phase1 Releae (http://ticket.ngms.info/versions/show/1) に従ったチェック)
下記各開発項目について、達成状況、現状の課題・懸案事項確認。提案事項
- ネットワーク自動取得
- config自動生成
- Device Tree 操作基本API
- NGMS Shell

2. NGMS Phase2(仮) リリース項目検討
下記各開発項目について、達成目標、克服課題・解消懸案事項の確認

- ネットワーク自動取得
- config自動生成
- Device Tree 操作基本API
- NGMS Shell

3. 仕様検討状況
- Incident管理

4. その他

--------------------------------------------------------------------------------

以上、よろしくお願いいたします。

[石川雅彦]

議事次第を掲示します。
よろしくお願いします。
(PPT と PDF は内容同一です。）

[石川雅彦]

Incident管理タグ仕様案を更新しました。議題の３で議論したく、よろしくお願いします。

[石川雅彦]

PDFとPPTは同一内容です。
３．仕様検討で議論したいと思います。

[石川雅彦]

Incident管理仕様案をウォークスルーし、更新しました。

[石川雅彦]

議事録を掲載します。 NGMS ML に送付したものと同じものです。

---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム　開発会議(第7回)　議事録
---------------------------------------------------------------------------

■日時: 2009年12月01日(火) 14:00 - 17:00
■場所: 名古屋大学 情報基盤センター 4F 会議室
■出席:(敬称略)
- 名古屋大学 : 河口、山口、情報基盤センター職員
- とりまとめ担当: 石川、山本
- ITプランニング(以下"ITP")
- 鈴木裕信事務所(以下"SH")
- SRA [TV会議]

■資料
1. 議事次第 (資料1_NGMS開発会議-第７回-091201-議事次第.ppt)
2. インシデント管理:仕様案 (NGMS仕様案-6.インシデント管理-20091201-02.ppt)
3. インシデント管理:チケットタグ仕様案(インシデント管理-タグ仕様案.odt)
4. ネットワーク自動取得: 内部仕様案 (NGMS仕様案-4.ネットワーク自動取得-20091201.ppt)
(以上、情報サイト http://ngms.info/ に掲載)

■議題
1. NGMS Phase1 リリースチェック
2. NGMS Phase2(仮) リリース項目検討
3. 仕様検討状況
4. その他
5. 次回予定

■議事内容
注：(*xxx)は担当者、実行者を示す。(*ALL)は全体

●1. NGMS Phase1 リリースチェック
(phase1 Releae (http://ticket.ngms.info/versions/show/1) に従ったチェック)
下記各開発項目について、達成状況、現状の課題・懸案事項確認。提案事項

【ネットワーク自動取得】

- どういうAPIが必要であるか、洗い出しは進んでいるか？
->必要な機能がどのようなものかはITPさんに伝えている。
前回打合せにてAPIの仕様がある程度把握できたので、そちらを使ってオーソライズする

- 保存機能はない？
+ NMPathを利用して保存する機能を用意するという選択肢もあるが、それは使い方の問題ではないか
+ 便利なAPIをきるか、ラッピングするようなAPIを作るかを選択する必要がある。

- 取得したときに、IPアドレスの範囲をスキャンするか？
->使う側で取得したIPアドレスを絞り込むことはできるが、
オプション等で設定して取得するという作りには現状ではしていない
->それもNMWalkerで取得できるようにしたい
+ コマンドのインタフェースをどうするかにより作り方が変わる
+ 現状ではスタンドアローンで動いてもよいのでは？
- 現時点ではライブラリ的な作り方を進めているという認識でよいか？
->はい。プリミティブが用意されていれば、組み合わせていろいろ用途を広げることが出来るという趣旨

【ネットワーク監視用config 自動生成】

- 今回はあくまでnagios・Cactiから、監視対象を追加するための機能を実装している
ユーザが新しくNagiosに設定したい場合、それをデーモン化するかどうかは使う側の問題との認識(SRA)

- DeviceTree にユーザが情報追加する必要がある
+ Config 機能にはどこに何があってというのは自動的にはわからない
+ Device Tree に監視対象の情報があるという前提。例えば、TAGのような形で。

- 自動生成した Config と、手で作ったのを分けるという方法がある
+ 自動生成された Config と手作成の Config でファイルや置き場所のディレクトリを分ける案はどうか？
+ config ファイルは include が可能。
+ include で、設定が被る場合は先読み優先？後読み優先(オーバーライド)？

- サービスとして死活監視をする。
+ 例えば何を監視対象にするか、サーバだったらサービスを動いてなければいけないとか、
対象の機種とか役割とかで監視対象が違うと思われる。
今後はその辺りの Best Practice を集めていくのが課題

- 仕組みがシンプルな時点で、試行錯誤を進め抽象化された仕組みに変えてほしい
->今回(Phase1)は"function prototype"として実装した。
->今後、この実装を基にリファクタリングしていく。

- ソースコードを基に、クラス設計、リファクタリングについて議論。
+ cactiとNagiosで書き方が違う。
例えば、configへのwrite方法として、nagiosは、writeConfigであり、cactiはaddDeviceとなっている。
->今後、リファクタリングを行うことが課題と考えている。
+ 他のツールに対応する場合に、追加コードを最小単位で出来るようにしたい
- 部品化するのが scala の理由
- cacti は PHP が無いと動かないのか
-> PHP を使用しないと厳しい。nagios config がtext だが、 cacti は DBに書き込むので。
- 今後、様々な config自動生成に対応するが、新たな対応のための実装を楽にするために、知恵を出す必要がある。
+ 抽象化できること、できないことを整理してほしい
->了解

【Device Tree 操作基本API】および【NGMS Shell】
- ツリー構造そのものをファイルシステムに交換していく
+ それらの基本的な API について検討してサンプル実装を行っている
だいぶ出来たが足りないものがあるので拡充していく

- 特にファイルシステムの機能を優先してやっていく
+ Subversion ファイルシステムの開発も必要

- シェルの方の機能からの要請で複数のファイルを並べて実行する必要がある

- 状況報告(API)
+ mountのみ実行可能
+ create file 、 description は作成済
+ operation : 下位オペレーションを呼ぶだけなので可能

- 異なる実装形式を跨るコピー機能はまだできていない
+ まず読み出しと書き出しだけできれば、まずはSRA側で使えると思う
+ 不足機能・要望機能についてはSRA側でスタブを作っておく

●2. NGMS Phase2(仮) リリース項目検討
下記各開発項目について、達成目標、克服課題・解消懸案事項の確認

【ネットワーク自動取得】

- 機能要求としてはサブネット指定で出来ればそれ以上はあまり考えるところはない？
+ ブロードキャストしかサポートしてないような仕掛けがある場合は検討要
+ 現状、コンシューマデバイスとかプリンタは考えなくて良い

【ネットワーク監視用config 自動生成】

- 資料4. ネットワーク自動取得: 内部仕様案 (NGMS仕様案-4.ネットワーク自動取得-20091201.ppt)
を基に説明（とりまとめ担当)

(資料4中、NGMSソフトウェア構成図について)
- 意義、目的は？
+ 1. 現状の設計把握
+ 2. 今後の設計方向がわかる。
+ 3. 開発担当毎の作業境界を明確にしたい。
- 結論
+ 1. 現状の設計把握 ... 現時点ではソースコードは多くないので、コードレベルで把握でよい。
設計的にどうなっているのかFixされていない状態なので
現状、改修点の議論にはソースレベルで行うほうがいい
+ 2. 今後の設計方向 ... 今やらなければならないことを先ずクリアし、方向性議論はその後で行う

(内部設計案について)
- 追加した機器そのものについて管理者は知っているから、自動発見機能は要望の本質そのものではない。
欲しいデバイス情報を正確に取得することが大事
- 論理ネットワークより物理ネットワークを知りたい。
+ LLDPで考えられているはずなのでそれを利用したい
- VLANがちゃんとつながっているのも把握したいが、今回実装するのは厳しいため
今回は先ず、物理LANがどうつながってるか把握したい


●3. 仕様検討状況

【Incident管理】
- 必要なStatusの種類とStatusの遷移について
+ 今のチケット管理(ngms.info)にあるレベルの機能は可能にしたい
+ 先ずは一つ進む、戻るというレベルが可能であればOKではないか？
+ カテゴリによって状態遷移が変えられるような仕組みが必要
+ 状態遷移を行うまでの制約条件が必要
+ 状態遷移時に情報通知をするシステムが必要か
+ ポーリングに行くべきなのか、デザインチョイスが必要

- チケットツリーの構成について
+ チケットがたまっていくと、整理したくなる
+ チケットがフラットに存在したとしても、スマートフォルダ的なものがあればよい
* スマートフォルダもキャッシュがあるのでそこまで遅くない

- Status の遷移のユースケースについて議論
+ インシデントの種類分けについて
* ネットワークが遅いというチケットがあって、そこで新しい機材を購入するという提案になった場合、
そのチケットはインシデントというより運用ではないか？
* インシデントのチケットのフォルダと運用上のチケットのフォルダを分ければいいのでは？
* 緊急対応したので後で上げなければいけないというチケットもある
* 分類は変更可能
+ closeしたのに直ってない場合は？
* 起票者が問題を提起したんだから起票者がクローズすると思われる。
* 運用方法までここで検討するものではない
* 差し戻したときの履歴が残り、通知が滞りなく行えばよいのでは？

- インシデント管理の実装担当はどのチームか？
+ インシデント管理の実装担当を決める必要がある。

- どういうイベントケース・シナリオがあるのかを出す(* とりまとめ担当、SH)

- エスカレーションのデータ構造について
+ 人がこういうエスカレーションしてくださいという設定するために在るもの
* 階層構造がいらないというのではなく、集合構造としてのどういうエスカレーションをするかという定義は必要
* 具体的なイベントケース・シナリオをたたき台として、議論をしたほうが良い
+ シナリオを書くためのエスカレーション条件(例)
* 誰に通知するか、時間帯、スケジューリング、別テーブルに入ってないと駄目、など。
* どのくらいの時間チケットが更新されないとエスカレーションするか？という条件：15分なのか、10分なのか
* 優先度が高いものはすぐにエスカレーションされる、など
* 発生時刻によって、エスカレーション先が異なる。(9:00-5:00PMの間のエスカレーションとそれ以外の場合、など）

●4. その他

- 課題管理(ngms.info)について
+ メンバーはコーディングの状態なので使われないのは仕方が無い
+ とりまとめ担当で、課題管理のページをコントロールする(* とりまとめ担当)

- ファイルのIDについて
+ どこかに何か置けと指示されてない場合には必要
+ NMWalkerのインスタンスを使う際、ためるべきパスが定義されているか、
返す機能が用意されているのであればIDは不要ではないか
->検索時：ディレクトリ上を検索し、descriptionの実体をnetwalkerに渡す。
->保存時：実体だけ渡し、ディレクトリ上のファイルを探し保存させる

- DeviceTreeを利用する側とAPIを提供する側の作業境界について
+ DeviceTreeAPI利用側も、DeviceTreeの構造や操作の実装を知ったうえで、実装して欲しい
+ DeviceTreeへの要望機能については、トラバースした実装をサンプルとして示す(* SRA)

- 今後の打ち合わせについて
+ 開発担当チーム(SRA, ITP,etc)でショートディスカッションを頻繁に進めてほしい。
* 開発会議よりも細かい頻度で。Skype などを使用して。
* 議事録を残す前提でショートディスカッションを頻繁に行っていく

●5. 次回予定
* 次回開催日時: 2009年12月17日(木) 15:00～(午後3時～)
場所: 名古屋大学情報基盤センター4F会議室

[石川雅彦]

4. ネットワーク自動取得: 内部仕様案 (NGMS仕様案-4.ネットワーク自動取得-20091201.ppt)

を掲載します。（PDF は同一内容です。)

[石川雅彦]

会議中、鈴木さんがディスカッションに使用した資料を添付します。