石川@とりまとめ担当です。
設計レビュー議事録をお送りします。
---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム 設計レビュー 議事録
---------------------------------------------------------------------------
■日時: 2009年11月25日(水) 16:00 - 18:30
■場所: (多拠点遠隔会議)
[名古屋]名古屋大学 河口研究室
[東京]SRA東京本社
■出席:(敬称略)
[名古屋]
- 名古屋大学 : 河口
- とりまとめ担当: 石川、山本
- ITプランニング(以下"ITP")
[東京]
- SRA
- 鈴木裕信事務所(以下"SH")
■議題
1. NMTree ソースコードレビュー
2. NGMS Shell設計書レビュー
3. ビルド方法、初期設定について
■資料
1. NMTree ソースコード
http://sourceforge.jp/projects/ngms/svn ... ?root=ngms
2. NGMS Shell設計レビュー
http://ticket.ngms.info/projects/list_f ... -shell.odt
■議事
1. NMTree ソースコードレビュー
資料1 に基づき説明(ITP)、及び質疑(ALL)
・ファイル構造
- 4種類の構造を用意している
1. Stream
2. Description
3. Table : CSVのようにカンマ区切りの形式
4. XML
- 暗黙的にStream型にcastしたほうがわかりやすい？
- 書込側・読込側双方で変換する手間が発生するため、シェル側でやってあげたい。
- Stream型が必要な場合は変換機能が用意されているのでそちらを使用する
・パーミッション
- ユーザがグループ分けされており、そのグループに対する権限操作
・NMPathとNMElementPermissions
- NMPathとNMElementPermissionsの名称：PermissionとPermissionsがある
-> 見直す(*ITP)
- trait した方がよいかもしれない。検討する(*ITP)
・メタデータを永続化する方法は？
-> IDを付けたいという話があったため、idをもっている(変更なし、Long型)
通し番号を検討したが、コミットにより番号が重なってしまう危険性がある。
Gidを生成してつけるしかないと考えている。
・障害により、NmPathがわからなくなったとき等はどうするのか？FSCKのような仕組みは？
-> 大半の情報はリポジトリに入っている。ファイルシステムが壊れない限りは再構築はない。
まず最初はファイル構造にマッピングするところから入っていく
・snapshotやdiffが取れるようにしてほしい。
・その他
- Plan9 の場合、マウントとバインドの二つがありプロセスごとにネームスペースを切り分けられる。
- アプリケーションプログラマにとって、実行前の一連の操作はしんどい
+論理パスを指定していきなり書かせるようにする方がやりやすい
-> NmShellという環境を用意している。そちらとの連携を取る形
- 基本的なところで読込み、それを使い続けられるようにするイメージであった
-> 方法を検討する(* ITP)
- APIの利用サンプルがほしい(河口)
2. NGMS Shell設計レビュー
資料2 に基づき説明(ITP)
(以下、ディスカッション)
・コマンドライン編集
- jlineライブラリを参考にしつつ作っていく形になると思われる
- 今後、ngmsline のようなものを作成する予定。
- キーバインド:設定ファイルにより、文字によって何を呼び出すかを指定可能
- emacsモード、 hidemaruモード、sakuraモード、などが用意されているとよい。
・コマンドの定義
- コマンドの文法と helpの文法と Web APIの文法が同時に書けるとよい。
cf. netconf (command line -> XML化)
- コマンドとhelpが一緒になったファイルがあり、それが実装にも使えるとよい。
- DSL で記述が簡単か。
・内部設計
- NGMSサーバに投げる方が処理が楽
- それではしかけが大きくなるのでは？
- 将来的な目標は、シェルのサーバにアクセスして呼び出すような形
-NGMS Shell の入力は、ユーザからの入力とは仮定しないように設計する。
+ ユーザからのコマンド入力だけではなく、XML等から受付けるような想定も考慮に入れて設計する
- 将来的にスカラインタプリタからXMLに出力できれば・・・
- Exception系の機能は、NMTreeOperationExceptionにて用意している
+ Exception系の充実は今後の課題(*ITP)
・コマンド仕様
- insdir はどのような機能か？
+ 新しい枝を作成し、接木する(mkdir⇒moveの組み合わせ)
+ APIの必要コマンド
- コマンド手順を作成(ITP)
- コマンドの詳細が出来た時点でManを作成(SRA)
3. ビルド方法、初期設定について
(1)ビルド方法
・Eclipse環境以外でもビルドを可能としたい。
・ビルド案 1) ant, 2) Maven 3) SBT(Simple Build Tool)
・自動ビルド、自動Unit Testができればそれでよい。
・現状の build.xml には eclipse依存の記述がある。非依存にできればよい
- build.xmlをantのコマンドで実行できるようにする(* ITP)
- maven、Simple Build Toolについて検討する(* ALL)
+ シェル常駐時にはSBTの方がビルドが早い
+ SBTはEclipse用のプラグインがまだ充実していない
+ mavenの方が普及している
- 公開時には開発ツールの一つとしてEcliseを案内することになる
・ビルドツールは今後も要検討(河口)
・scala的な記述方法について
- NMPathでの使用例を紹介
- 公開関数を積極的に活用していく
+ mountは単純にマウントポイントを決めるために存在
-> それでは自動取得したIPアドレスをどのパスに自動配置するのか決められない
-> 取得情報のパスの置き場を決めるのは人が行う
-> 既登録のIPアドレスに情報を自動追加するという用途はある
(2)初期設定
・設定ファイルのconvention を決定する必要がある。
設定ファイル: config ファイルなど。
・ configファイルをどこに置くのか
- configタグがどこにあるという程度で抽象化すればよい
- configを読込むための共通ライブラリを使用させる