You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is hard to reason about TEManager because of the amount of state it keeps around, and because of the ways to add/update topologies to it. For example, we instantiate and use TEManager like so:
manager=TEManager()
fortopologyin [topology1, topology2, topology3]
manager.add_topology(topology)
...
# Remove/hide update_topology(). Instead, add_topology() will do the update if a topology already exists.manager.add_topology(updated_topology1)
...
graph=temanager.generate_graph_te()
traffic_matrix=temanager.generate_connection_te(request)
...
When testing SDX Controller, a new issue surfaced that was not caught in unit tests. I have not managed to capture all the details. This issue is a reminder to myself to investigate this later.
When SDX Controller starts up, it attempts to restore at least some of its previous state by loading the combined topology from the database. When we add further topologies to this, and then try to place a connection request, PCE fails to find a path.
It was the original static topologies that were re-added, and it was the sample static connection request that we tried again. It sounds like we could add a new test: keep adding the same topologies over and over again, and make sure that nothing breaks.
It is hard to reason about TEManager because of the amount of state it keeps around, and because of the ways to add/update topologies to it. For example, we instantiate and use TEManager like so:
It would be nicer to use TEManager like so:
This is related to this TODO item:
pce/src/sdx/pce/topology/temanager.py
Line 34 in d18c67e
The text was updated successfully, but these errors were encountered: