2009年11月17日第６回開発会議

[石川雅彦]

石川@とりまとめ担当です。お世話になります。
以下の要領で会議を開催します。よろしくお願いします。

■日時:2009年11月17日(火) 15:00(午後3時) -
■場所:名古屋大学 工学部 7号館 1階 704 講義室
交通: (地下鉄)名古屋市営地下鉄 名城線 名古屋大学駅 3番出口最寄り
http://www.nagoya-u.ac.jp/global-info/a ... gashiyama/ の 35番の建物
またはhttp://www.engg.nagoya-u.ac.jp/access/access.html の "7号館"

--------------------------------------------------------------------------------
■検討予定項目

・開発状況の確認、課題・懸案事項確認
- phase1 Releae (http://ticket.ngms.info/versions/show/1) に向けての状況確認
・機能仕様及び内部設計の検討
・phase1 Releaseまでの予定、作業項目確認
・その他

[石川雅彦]

とりまとめ担当の資料を添付します。

[石川雅彦]

議事次第を添付します。

[石川雅彦]

石川です。
開発会議は予定通り開催されました。
（出席のみなさま、お疲れさまでした。)

議事録を作成しました。
何かあればコメントくだされば幸いです。> ご覧のみなさま

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

■日時: 2009年11月17日(水) 15:00 - 17:15
■場所: 名古屋大学 工学部 7号館 1階 704 講義室
■出席:(敬称略)
- 名古屋大学 : 河口、山口、石原
- とりまとめ担当: 石川、山本
- ITプランニング(以下"ITP")
- 鈴木裕信事務所(以下"SH") [TV会議による参加]
- SRA [TV会議による参加]

■資料
NGMS開発会議-第6回-091117-議事次第.ppt
NGMSプロジェクト管理方法案-20091117.ppt
NGMSプロジェクト情報共有手段一覧.xls
NGMS仕様案-6.インシデント管理-20091117.ppt
NGMS仕様案-A2.コマンド体系-20091117.ppt
NGMSコマンド体系-20091117-会議.mm

■議題
1. 導入(会議方針、経緯の説明)
2. 議事詳細
　　　2.1 Phase1 Release(2009/11/30) に向けての状況確認
　　　2.2. インシデント管理：システム概要
　　 2.3. プロジェクト管理案説明
3. 次回予定調整

■議事内容
※以下(*xxx)は担当者を示す。(*ALL)は担当者がSRA,ITP,SHであることを示す。

1. 導入
・過去の会議履歴と、会議の運営方針の再確認

2. 議事詳細
2.1 Phase1 Release(2009/11/30) に向けての状況確認
プロジェクト管理サイトに掲げられた Phase1目標(http://ticket.ngms.info/wiki/ngms/Phase1)
に沿って、各人の進捗を確認。

(1) 機器のIPアドレス / SNMP Communityを設定すると、情報を自動取得
・進捗状況（SRAより)
- Perl版から Scala版への改修途中。Perl版と同一の動きは完成
- Perl版をそのまま置き換えているため、リファクタリング等は未実施
- 外部ライブラリを使っているため、commit前に相談したい
・課題
- クラス分けの明確化
- 汎用的に使えるようにする
- その他リファクタリング
+ OID など。
- 課題やリファクタリングすべき項目については見つけ次第、MLに提議する(*ALL)
・クラス図の記述について
- UMLのローカルルールを定めたので、それを使用して作成する。
・テストについて
- 今後のUnitテストの際は "Scala Test" を使用する
- 実際のネットワーク機器を使用したテスト環境構築について
+ 構築中(*河口)
+ 試験環境についての要望を出す(*SRA)

(2) 自動取得したデータ(Device Tree)から各種ソフトウェアへConfig作成
・進捗状況（SRAより)
- 以前作成したscala版のソースからは特に進捗なし
- nagios用機能だけが稼動可能で、cacti用機能は進んでいない
- nagios用もcacti用もある程度稼動できる状態で実装してほしい
・課題
-グラフの種類やログファイルの出力先など、人が決めるべき箇所の構築は困難
=> そういう課題は phase2 で解決していくべき事である
課題を集めるためにも phase1 でのサンプル実装が必要

(3) Device Treeを操作するための基本API
・進捗状況（ITPより)
- NMTree をリポジトリに commitした
- クラス図も commit した。
・MNTree クラス図説明。質疑応答
・担当
- Device Tree は ITP で担当する
- 使用者視点からの課題があれば、MLに提議する(*SRA)

(4) Device Treeを操作するためのShell
・ 設計実装：進捗状況(ITPより)
- API作成後、11月末までにある程度の形で仕上げていく(*ITP)

・ 機能仕様検討:進捗状況(とりまとめ担当より)
- コマンド体系を検討(資料:NGMSコマンド体系-20091117-会議.mm)
・質疑応答、ディスカッション
- shellがコンテキストを持つのではなく、外だしにしておくべき
- このコマンド体系を機能に盛り込んでいく(*ITP)

・ Shell仕様に関するディスカッション
- netconfが参考になる。
+juniper のコマンドは netconfに対応している。
+ コマンドは内部的に XMLで書かれている。
+ ファンクション対API対shell、というように対応づけられている形が理想
+ API用のXMLファイルを作るという形がよいのでは。

・派生ディスカッション
- NGMS Shell に版管理機能を盛り込むべきか？
+ ユーザが明示的に行なうか、またはShellに組み込むべきか。
+ ベストプラクティスを探す必要がある。
+ NMTree には実装がある。
+ 失敗した時にロールバックする必要があるが、面倒。
+ グローバルコミットとローカルコミット

(5) 進捗報告(SHより)
+ セキュリティインシデントを検討していた
- 現行で存在するセキュリティポリシーを参考に提起していけばいいと思う

+ Escalation のモデルをどうするか？
- SH、石川で打ち合せを行う(*SH、石川)

2.2. インシデント管理：システム概要
・資料：NGMS仕様案-6.インシデント管理-20091117.pptに基づき、
初期検討項目を説明。
(1) incidentを登録する
- ファイルのスキーマに必要なタグを検討
(2) ステータスを更新する
+ NGMSのファイルシステム
- CSVみたいなテーブル形式？
- 特定のファイルの特定の部分を更新する、というような処理は可能か？
-> 可能。困難ではない。
(3) エスカレーションする
+ この機能については、システムが自動処理を行う仕組みである
- 対話があってエスカレーションがある、という仕組みが望ましい
+ ツリーよりもワークフローのように順番で参照できる方が可視化しやすい？
- インシデント種類によってツリーとワークフローでつなげ方を変える
(4) 処理状況を参照する

・(1)(2)(3)(4)の検討を通じてインシデント管理ツリーの検討も行なえるだろう。

・以下の点を仕様検討する(*SH、石川)
- エスカレーションの条件
- タグの記述方式

・incident登録の検討
- TAGを使ってincidentを記述し、ファイルに落として、そのファイルを incident登録することを想定。
・インシデント管理はPhase1の次のタイミングで実装
- 機能仕様を書き下ろす(*石川)
・ポイントは incident登録のタグ、エスカレーション条件だと考えられる
・TAG
- XMLではなく、: セパレートの フォーマットで
- Naming Convension をしっかりと。ITIL から引用？
- TAGのコードは? ... UTF-8 で後でコンバータを入れる
・エスカレーションの検討
-エスカレーションツリーはディレクトリの深さで表現
+ States Update のような形でエスカレーションさせるとよいのでは？
+ エスカレーションはインシデントの種類によって変わる
+ エスカレーションはシステムが行なうが、システム側ではディレクトリである必要はない。
+ネットワーク機器、無線LAN、サーバーなどエスカレーション対象担当者が違う
+ 名大での利用を想定した、エスカレーションの案を作成する。(*名大石原さん)
担当者はA、B、Cと抽象化で良い
+エスカレーション案ができたら、関係者でレビューする。翌週始め目処に(*SH、石川、石原)

2.3. プロジェクト管理案説明
(資料：NGMSプロジェクト管理方法案-20091117.ppt)
(1) Phase1の担当と詳細の案
1.ネットワーク自動取得
2.config自動生成
3.Device Tree操作基本API
-レビューは全体でやるのでは？
-レビューとなると明確なエビデンスが必要
-レビュー →　コメントに変更する。
+ 各自でコメントを積極的に書く(*ALL)
4.DeviceTree操作Shell
- Shell仕様のすべてはPhase1では含まない。
- API、シェルスクリプトのレビュー実施
+ 11/25(水) 16:00～ ソースコードレビューを実施
+ 媒体：Skype、VNCを使用
+ 準備：各自Build環境を整えておくこと(*ALL)

・Phase1の目標、担当、期日をTicket登録する。

・プロジェクト管理(NGMS Project Redmine)の使用意義とルール(*ALL)
- マネージメント側からは、いつまでに終わるのかを把握したい
- 一日で終わるような作業はチケット化しない
- 誰がやるのか不明確なものについてはチケット化する

(2) 課題管理方法
・プロジェクト管理サイトで集中管理
・目的
- 開発メンバーでの解決しなければいけない問題がどれくらい残っているのかが知りたい。
- 問題が誰が担当しているのか、担当していない問題はないか把握したい。
・ticket登録すべき課題
- 時間がかかる課題
- 誰かに関係しそうな課題
- 担当がわからない課題
・ticket登録すべきでない課題
- 1日程度ですむ課題
- 作業したらおしまいとなる課題

(3) プロジェクト情報共有手段
(資料：NGMSプロジェクト情報共有手段一覧.xls)
+ アップロード、提起場所
- ngms.info 会議資料
- ticket.ngms.info 仕様書やコーディングルール等細かく変わるもの
- sourceforge ソースコード
- ngms ML NGMSに関する議題
- ngms-sw-wg ML サブシステム等、細かい議論

・クラス図はリポジトリに入れるよりはプロジェクト管理
・会議資料は掲示板にupする。
・文書管理は（会議資料とソフトウェア開発資料）に分ける。
・NGMS掲示板
- 履歴が残るもの
- 文書管理のうち、開発会議に関する文書を置く。
・プロジェクト管理サイト
- 結果を残す
- Wikiも活用。変更が多いものはWikiをつかう。コーディング規約など。
- 文書管理のうち、ソフトウェア開発に関する文書を置く。
=> excel資料をwiki形式に書き換えてアップロードする(*石川)

3. 次回予定調整
* 次回開催日時: 2009年12月01日(火) 14:00～(午後2時～)
場所: 名古屋大学情報基盤センター4F会議室
11月30日リリースした後のリリースチェック会議

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

[石川雅彦]

11/17開発会議の会議資料を添付します。
よろしくお願いします。

[石川雅彦]

開発会議資料(2)です。

議事録とあわせて参照いただければ幸いです。

なお、NGMSプロジェクト共有手段一覧は、"プロジェクト管理サイト" http://ticket.ngms.info/" の Wiki にも up する予定です。
よろしくお願いします。