meeting_20180314

2018-03-14 打合せ

日時: 2018-03-14（水）16:00-
場所: W207
参加: 岡別府、藤澤、児玉、運用チーム（藤本、佐藤）

アジェンダ

• ルール実装の進捗確認
• ルールの調整事項
  • SSM validator 実装
  • 必須がないときのチェック
  • taxonomy id チェック関連
• 運用開始に向けての調整
  • Nagios 監視
  • スパコンチームへの依頼内容
  • ウェブサイト
  • d-way release 後の不具合、要望など
  • validator の deploy 手順
  • リリーススケジュール
  • バージョン管理
  • バリデーションログの解析ツール
• その他

ルール実装の進捗確認

• BioProject Validationの実装(岡別府)　(27/27ルール)
• DRA Validationの実装(岡別府)　(29/32ルール)
• BioSample Validationの実装(岡別府)　(追加1ルール) => 追加して本番環境にデプロイ済み(サンプル名100文字以内チェック)
• biosample package の rdf に tsv での提供順情報を持たせる (藤澤)
  ← package 指定毎の attribute リストを順番に取得する SPARQL 教えてください（児玉）
• 更新手順書等ドキュメント作成 => 作成中
• Annotated Sequence Validator（TogoAnnotatorの利用）の実装開始

ルールの調整事項

必須がないときのチェック

D-way: 必須属性値がないとき属性そのものが無い
validator: header にないではなく値がないというチェックをするように改修

taxonomy id チェック関連

まとめ docs

運用開始に向けての調整

Nagios 監視

• staging監視
  1月の打ち合わせで、藤澤様からスパコンチームに依頼していただくことになりました。
  運用チームでは追跡していませんが実施済みでしょうか。→ 2/20 スパコンチームに依頼済

スパコンチームへの依頼内容

次の事項を依頼予定 → 2/20 スパコンチームに依頼済

• Staging環境のTimeout 300 / KeepAlive Offの設定については元に戻して頂く(本番環境と揃えるため)
• 403の設定については、現状効いていないので提案する設定を渡す

現行設定

<Location /api>
  Require ip (制限許可IPの記述)
  ErrorDocument 403 /api/forbidden.json
</Location>

修正後設定 (内容:"/api/"であり"/api/error_*.json"ではないURIにアクセスをかけるように修正)

<LocationMatch "/api/(?!(error_.*\.json))">
  Require ip (制限許可IPの記述)
  ErrorDocument 403 /api/error_forbidden.json
</LocationMatch>

ウェブサイト

D-way側でもルールに対してリンクを貼ってユーザが確認できるようにする(運用 T)。 --> 対応済み 16 リリース
Validation Rules ページ公開済み
https://www.ddbj.nig.ac.jp/biosample/validation.html#BS_R0003

お知らせ（導入予告）
https://www.ddbj.nig.ac.jp/news/ja/180314.html

validator の deploy 手順

reference array --> string で biosample 内部管理システムでエラー発生

• validator deploy 手順、情報共有方法
• まずは D-way DDBJ 管理システムのテスト版でチェック
• 本番リリース

という手順ルールを定めたい

本番リリース時のダウンタイム

Unicornでダウンタイムなしの本番リリースができるか確認中。通常はデプロイ2分(この間は影響ないはず)、Unicorn再起動に30秒ほどかかる

リリーススケジュール

1. 3/16 スパコンメンテ明け D-way/SSM tax id 必須でリリース
2. 3/22(?) tax id 任意で再リリース

バージョン管理

• ルール及びパッケージの定義に関しては、GitHubでレポジトリを分けて管理する(★児玉)
  => https://github.com/ddbj/pub で作成済み
• バリデーションでこれらルールを取り込むタイミングで日付に基づいたバージョンをつける。取り込む際はルール定義=>JSON、パッケージ定義=>OWLに変換するので、変換したものにバージョンを付与する。
• バリデータについてはデプロイするタイミングでバージョンを付与する。これはセマンティックバージョニングになる(1.0.2等)
• APIの仕様(メソッド)を変える場合にもバージョンをつける。稀にしか発生しないのでこれもセマンティックバージョニング。
  • APIのバージョンについては、全てのバージョンの定義ファイル(openapi.json)を残しておき、バージョン毎にさせるようにする。バージョン指定がない場合は最新バージョンの仕様を返す。

バージョンをあげるタイミングと手順
https://docs.google.com/document/d/1-4ya4SbQtP4iVzZXvGQbIDYdV-FSqgGdbly380JMQik/edit

バリデーションログの解析ツール

logのディレクトリからfindでファイル出力しようとしたが、ファイルが多すぎるのかt013で既に返ってこなかった。

• 統計用にUUIDリストを出力する必要がある
• 死活監視のデータは定期的に消去(5分置きなので蓄積されていく)

次回

3/30(金) 10:00〜

メモ

Validatorのデプロイについて

デプロイ時の動作確認

• 結果JSONのフォーマットが変わるとD-way,SSMでも対応が必要になり、運用Tに連絡して動作確認してもらう。
• 本来JSONフォーマットが変わる時点でAPIのバージョンを変えるべきだが、バージョン並列運用の環境はできていない。
• フォーマットが変わらなければ運用Tの確認は不要で、児玉さんがD-way,SSMのステージング環境でテストを行ってデプロイ許可を出す。
• 動作確認のためのテストファイルを決めておくことが望ましい。

デプロイのタイミング

• D-way,SSMに影響がなければ、Validatorマターで決めてよい。
• D-way,SSM側は毎月第2水曜日の午前に定期更新するので急ぐ修正でなければValidatorはこれに合わせても良い。
• デプロイ時にダウンタイムが発生する可能性があるが、極力短く済むようにする。

TaxID任意化のデプロイについて

• TaxonomyID任意化版のリリースについては、D-wayのUIにも変更があるのでできる限りタイミングを合わせた方がいい。あらかじめ日時を決めてから作業すること。
• Validatorがデプロイの準備を整えられたら運用Tに連絡する。

バージョン管理

最終的には以下資料のような手順になる(オレンジ字は本日検討した結果)。 https://docs.google.com/document/d/1-4ya4SbQtP4iVzZXvGQbIDYdV-FSqgGdbly380JMQik/edit

リリース時に行う作業をチェックリストで用意しておく

ルールのバージョン管理

• 現行の管理に使っているルールスプレッドシートを原本として今後もルールを修正し、バージョンを振って本番にデプロイした時点で公開用ルールにも変更をコピペする。二重管理になるが避けられない。
• 現行の管理に使っているルールスプレッドシートの明らかに不要なカラムは削除する(岡別府)

パッケージ定義

• パッケージセットとしてバージョンを振る必要がある。ルール定義と違いGitHub上に実体ファイルがあるため、このファイルを更新した時点でバージョンを振る。
• RDFを生成する場合はこのバージョンを指定して生成し、ロード時にはグラフ名にバージョンを含める。

TaxID任意化の検討

• TaxID:1(root)を特別扱いする必要はない
• TaxID優先としていたが、organismの入力が必須でありこちらを優先(TaxIDからOrganismを引くのではなく、OrganismからTaxIDを引く)
• フロー図を修正する(図を修正中)
• いつ頃リリースできるか決まったら連絡する(岡別府)