Remove topology from .conf file

[y-higuchi]

Network DSL .confに明示的にtopologyの記載を不要とする。

#5 run 除去の影響

• topologyの無条件起動 or 遅延起動の選択
  • 遅延起動の場合、topologyの起動とOVS起動タイミングが変わる。(topologyが後起動)
    • 既存スイッチ一覧を取得し、擬似的にswitch_readyをtopology内でシミュレートが必要。
    • 既存スイッチに対して、port_status/state_notify をtopologyにも通知するよう登録。
    • 複数topologyプロセス起動ケースの表現
      • CLIでtrema run topology -n topo2が必要でOKなら実現可能。
  • 無条件起動の場合
    • event/filter除去の影響の内、起動済みswitchに対するケースを省略出来る？
      • 複数topologyプロセス起動ケースでNG
    • switch_managerにて、とりあえずは、switchがtopologyへイベントを飛ばすようハードコードする方法も取れる？
      • 複数topologyプロセス起動ケースでNG
    • 複数topologyプロセス起動ケースの表現
      • 1つはデフォルト名となってしまってOK、また後続もCLIでtrema run topology -n topo2が必要でOKなら実現可能。

#2 event 除去の影響

• スイッチイベントのtopologyへの配送
  • (今後起動してくるスイッチ用に)switch_manager に対して、
    port_status/state_notify のイベント転送先としてtopologyを登録。
    • 現在外部インターフェイス無し、 要switch_manager改造 Add dynamic event forwarding I/F to switch daemon/manager #7
  • 起動済みのswitch に対して、port_status/state_notify を転送先としてtopologyを登録。
    • 現在外部インターフェイス無し、 要switch(daemon)改造 Add dynamic event forwarding I/F to switch daemon/manager #7
• LLDPのみtopologyへと配送するため、packetin_filterの挿入
  • eventが除去された場合、packet_inはデフォルトfilterになる？
    • NOの場合、topology登録と同様にpacket_inイベントをfilterに飛ばすよう登録が必要。

#1 filter 除去の影響

packetin_filterをはさみ続けるか、直接packet_inを2又に分けtopologyでも、ハンドリングし、
LLDP以外を捨てるか。

• packet_inフィルタが常に有効になるような場合、既存APIでフックするのみで良いはず。
  • Discoveryを有効化するとLLDPがユーザコントローラに届かなくなる
    • .confに書かせていた場合、必然的にユーザが認識しているはずだが、だれかがDiscoveryを有効化するとLLDPが届かなくなるのはOKか？
• switch_manager/switchに直接枝を張るのであれば、合わせてpacket_inも直接拾っても問題ないのでは？
  • Discoveryを有効化するとユーザコントローラに突然LLDPのpacket_inが届くようになってしまう
    • 従来から外乱がいた場合、潜在的には届いていたはずなので問題ない？

参考: 現在のtopologyを使用する場合の.conf例

#(Network Definition)

run {
  path "./objects/topology/topology"
}

event :port_status => "topology", :packet_in => "filter", :state_notify => "topology"
filter :lldp => "topology", :packet_in => "dumper"

[yasuhito]

👍