inmanta / nfv-test-api

API for testing network functions using network namespaces (archived)
https://code.inmanta.com/solutions/tools/nfv-test-api
3 stars 0 forks source link

[V2] Moving interface in up state to new namespace raise a 404 #25

Closed edvgui closed 2 years ago

edvgui commented 2 years ago

When moving an interface to another namespace while the interface is up, the server will bring it down, move it, then put it back up again. The latest action will raise a 404 because the server still tries to find the interface where it used to be, not where it has been found.

The interface is actually moved as expected, but will stay in a down state.

There is already a mechanism to handle those kind of situation in the code: we attach the host the interface is on to each interface object we generate, that way we know on which host to run the next action for this interface. This mechanism has some week points and should be reviewed/improved.

To reproduce it:

  1. Create an interface
  2. Bring it up
  3. Create a namespace
  4. Update the interface to go into the newly created namespace
edvgui commented 2 years ago

Implementation proposal:

  1. Move all set_... operations from the service to the IpModelBase object. Those operations should return a copy of the object after the modification has been applied.
  2. Setting attributes should be blocked on those IpModelBase if possible, to decrease the chances of any bad usage of the services
  3. Always keep the host object close to the IpModelBase object, in an attribute probably, this object should be used to run any command to apply any modification.
  4. IpBaseModel object should have a load/reload/clone method, taking the identifier and the host in attribute and returning a copy of the object in the latest state on the host
  5. set_... operations shouldn't use the get_one method from the service, but the load/reload/clone method from the object