Re: [openstack-dev] [neutron][taas] Asynchronous TaaS APIs
Hi Anil, >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. I think we may also need Pending-Update, if there is any focus of updating a tap-flow/tap-service in the future. But yes, such states should exist as most of the processing should not be presented to the user ( i.e. User should not wait for a CLI/UI function to complete), specially if a lot of processing is required. >For the former case,subsequent queries of the object's state will indicate if >the operation has completed, is still pending or has failed. Instead of polling, a callback can act as an interrupt and inform the frontend about Success/Failure of a job. -- Thanks and Regards, Reedip Banerjee IRC: reedip __ 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
[openstack-dev] [neutron][taas] Asynchronous TaaS APIs
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
