atlanticwave-sdx / kytos-sdx

MIT License
0 stars 3 forks source link

OXP side component should not depend on SDX-LC #41

Closed YufengXin closed 1 month ago

YufengXin commented 6 months ago

OXP side component should be able to run independently, otherwise it's a deviation from the architecture design. (we could re-discuss the architecture if needed.)

lmarinve commented 6 months ago

The code has been refactored to be independent of SDX LC and Kytos. It is now an asynchronous application based on Python Swagger Connexion, making it more compatible with SDX LC and not dependent on Kytos. This enables it to be used with other applications like OESS or any OXPO, not only as a Kytos network application. it can be tested here http://67.17.206.221/

italovalcy commented 1 month ago

Hi,

As far as Topology is concerned, the Kytos SDX Napp works in two methodologies: 1) Pull Topology 2) Push Topology

When supporting Pull Topology, it means that Kytos SDX Napp will work independently of any external component and make the topology available for anyone pulling the Topology (i.e., sending GET requests to obtain the topology). In other words, Kytos SDX Napp will just be listening for GET requests from SDX-LC and providing the converted topology. There is no dependency on SDX-LC here.

While supporting Push Topology, of course if we will push the topology we will push the topology to somewhere! That "somewhere" is exactly the SDX-LC. So we configure Kytos SDX Topology with SDX-LC REST endpoints that receives the topology. Then, upon and operational or administrative Kytos topology events, we do send the topology to SDX-LC. Of course, here we have a clear dependency on SDX-LC. However, that is by design: if we were to push the topology, we have to depend on that component.

Having said that, I believe this issue can be closed.