The Quantum API presents a logical model of network connectivity consisting of networks, ports, and attachments. It is up to the Quantum plugin to communicate with all managed virtual and/or physical switches to ensure that these devices implement packet forwarding behavior consistent with the logical model.
The plugin's task of mapping from the logical model to the physical world might happen asynchronously. This means that when an API client modifies the logical model using an HTTP POST, PUT, or DELETE, the API call may return prior to the plugin performing any modifications to underlying virtual and/or physical switching devices. The only guarantee an API client has is that all subsequent API calls will properly reflect the changed logical model.
As a concrete example, consider the case where a client uses an HTTP PUT to set the attachment for a port. There is no guarantee that packets sent by the interface named in the attachment will be forwarded immediately once the HTTP call returns. However, there is a guarantee that a subsequent HTTP GET to view the attachment on that port would return the new attachment value.
![[Note]](../common/images/admon/note.png) | Note |
|---|---|
Future versions of the API may expose a notion of an "operational status" on a logical entity like a network or port. This would indicate whether the Quantum plugin had successfully configured virtual and/or physical switches in order to implement the network connectivity described by that element of the logical model.
For example, a port might have an operational status of |
