設定ファイルエディターをつくる方へ
JANOG43 でライトニングトークしてきました
- NETCONF向けのコマンド(xml) とCLI向けのコマンド(text) が似ているため、XMLスキーマから抽象構文木が作れる
- 抽象構文木からエディターを作れる
- ためしにJunos向けの実装をしてみたが、他ベンダー向けもできるはず
簡単にいうと このような内容の発表をしてきました。
時間の関係で話せなかったことなどを、こちらにまとめておきます。
頂いた質問に答えます
いくつか質問を頂きました。ありがとうございます！
Q: オフラインでも使えますか？
A: 使えます。
発表ではこのような説明をしましたが、実際にはXMLスキーマを扱いやすい形 *1 に変換し、vscode拡張の中に同梱しています。ネットワーク機器との通信は不要で、オフラインでもOKです。
Q: XSDとYANG、どちらを使いました？
A: XSDを使いました。
詳しくは後述しますが、結果的にJunosではXSDを使ったものの、他でやるならまずYANGを試してみると思います。
設定ファイルエディターをつくる方へ
さて 本題ですが、あまりに誰得すぎて発表前に消したスライドがあります。実際にエディターを書く人向け。
せっかくなので、このスライドについて 補足します。
XSDとYANG、どちらを取るか
とりあえずはYANGがオススメです。
- 標準化されたフォーマットだから
- 抽象構文木を作成するにあたり、単一手法で複数プラットフォーム対応できる可能性がある
- パーサー実装があるから
- サイズが小さいから
- たとえばJUNOS 17.4 の場合、XSD 102MB に対して YANG は18MB しかありません。だいぶ楽
しかしながらJunosの場合、XSDのほうが便利そうだった
一番のポイントは、大量のメタデータが使えることでした。下は一例ですが、エディター実装時にはとても役立つ情報です。
<xsd:annotation> <xsd:documentation>Policy Name</xsd:documentation> <xsd:appinfo> <flag>mustquote</flag> <flag>identifier</flag> <flag>nokeyword</flag> <flag>current-product-support</flag> <regex-match deprecate="deprecate">^.{1,64}$</regex-match> <regex-match-error deprecate="deprecate">Must be string of 64 characters or less</regex-match-error> <match> <pattern>^.{1,64}$</pattern> <message>Must be string of 64 characters or less</message> </match> <identifier/> </xsd:appinfo> </xsd:annotation>
- それが識別子であるか、クォートが必要かどうか、など
- バリデーション失敗時のメッセージ
<xsd:annotation> <xsd:documentation>Source address filters</xsd:documentation> <xsd:appinfo> <flag>oneliner</flag> <flag>homogeneous</flag> <flag>autosort</flag>
<xsd:annotation> <xsd:documentation>List of captive portal content delivery rules</xsd:documentation> <xsd:appinfo> <flag>current-product-support</flag> <products> <product>mx960</product> <product>mx480</product> <product>mx240</product> <product>mx80</product> <product>mx80-48t</product> <product>mx5-t</product> <product>mx10-t</product> <product>mx40-t</product> <product>mx80-t</product> <product>mx80-p</product> <product>mx2020</product> <product>mx2010</product> <product>ex9204</product> <product>ex9208</product> <product>ex9214</product> <product>mx104</product> <product>vmx</product> <product>vrr</product> <product>mx2008</product> <product>mxtsr80</product> <product>mx10001</product> <product>mx10002</product> <product>ex9251</product> </products> </xsd:appinfo> </xsd:annotation>
- サポートするプラットフォーム一覧
一方、IOS-XR はYANGがよさそう
- メタ情報が少ない
- ファイル構造がほとんどYANGと同じ
このような理由で、もしIOS-XRでやるなら YANGを試すと思います。
NETCONFコマンドとCLIコマンドに差分がある場合の対応
Junosの場合 感覚的には「95% くらい同じ」と言えますが、やはり若干の差があります。
代表的なものは隠しコマンドの扱いです。XSD や YANG に隠しコマンドは記述されていません。
抽象構文木(AST) 生成元であるXSD / YANG は、ベンダーの都合で更新されます。それに引きずられることなく文法修正するために、一旦オレオレ記法で中間ファイルを作っておき、そこにパッチしていくと便利です。
XSDの場合には、大幅にサイズ削減できるという効果も狙っています。エディターに同梱するのは最終形態なので結果同じにはなりますが、開発中に何度もXSD本体をパースする必要はありません。
ライセンス
今回発表したやり方でいくと XSD / YANG をエディター処理系のデータ構造に変換し、エディターに同梱し、二次利用することになります。
問題ないことが多いとは思いますが、これがベンダーのライセンスに抵触するかどうかについて 確認しておくと安心です。
*1:JavaScriptで、巨大なObject
