The current tap-service-* and tap-flow-* APIs are synchronous. When the call completes a status of success or failure is returned. The problem here though is that this status is being returned by the TaaS plugin after it goes through some checks and successfully updates the configuration state. One of the operations performed by the plugin is to issue tasks to the TaaS agent/driver. However, failures encountered by the latter don't get returned back to the user. This can lead to problem situations where the configuration state might reflect that tap-services and/or tap-flows have been successfully created, but in actuality that may not always be the case. I think we should adopt an asynchronous model, where we maintain the state for tap-service and tap-flow objects. Valid states could be "created", "create-pending" and "failed." In addition, we will need a suitable mechanism to have the plugin extract the current state from the agent/driver and provide it to the end-user. Another scenario where the asynchronous model with states (as described above) will be useful is for TaaS backend implementations that may take a while to complete certain operations. In this situation, the front-end doesn't need to block completely; it can return as soon as the request is successfully handed to the agent or if the config tasks itself failed. For the former case, subsequent queries of the object's state will indicate if the operation has completed, is still pending or has failed. Thoughts...? Anil
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
