vsw client does not implement a controller at this time. it essentially has an agent in the background and a simple CLI which makes request to the agent through its 8021 adminAPI. So each individual CLI command runs to completion with no state. Each reads states out of the agent through its adminAPI GETs and makes service requests through POSTs.
Without a controller with webhook, there is no return path for vsw. The argument was that it did not seem to need one for the simple short term requirements. (Long term, this won't work, of course). But even in short term, this lack of a controller is causing several issues:
(1) A vsw CLI command makes a POST request to the agent and exits without waiting for a webhook callback. During that period before the agent completes, the user can issue another command which isn't consistent with the state. There will be no way to know if two commands interleaving will or will not cause problems. So for state consistency, the vsw must wait for a webhook call to come back before exiting.
(2) Without a controller, each CLI command must be very simple, not requiring state management or failure handling. This is not always possible. We would have to anticipate all possible failure mode and design a CLI command to recover from it.
(3) Interaction is difficult to do: TAA acceptance, e.g. may be a lot easier to handle?
Note: this bug is only documenting potential problems in the context of the "short term" needs. For longer term purposes, a controller is a must of course.
wenjing
commented
3 years ago
vsw client does not implement a controller at this time. it essentially has an agent in the background and a simple CLI which makes request to the agent through its 8021 adminAPI. So each individual CLI command runs to completion with no state. Each reads states out of the agent through its adminAPI GETs and makes service requests through POSTs.
Without a controller with webhook, there is no return path for vsw. The argument was that it did not seem to need one for the simple short term requirements. (Long term, this won't work, of course). But even in short term, this lack of a controller is causing several issues:
(1) A vsw CLI command makes a POST request to the agent and exits without waiting for a webhook callback. During that period before the agent completes, the user can issue another command which isn't consistent with the state. There will be no way to know if two commands interleaving will or will not cause problems. So for state consistency, the vsw must wait for a webhook call to come back before exiting.
(2) Without a controller, each CLI command must be very simple, not requiring state management or failure handling. This is not always possible. We would have to anticipate all possible failure mode and design a CLI command to recover from it.
(3) Interaction is difficult to do: TAA acceptance, e.g. may be a lot easier to handle?
Note: this bug is only documenting potential problems in the context of the "short term" needs. For longer term purposes, a controller is a must of course.