While reading up the specs in [1] and [2], there are certain things which we may need to discuss before proceeding forward
a) Reference point for Ingress/Egress traffic: There may be some confusion related to how we are labelling Ingress and Egress ( is it with respect to a VM, with a switch , or any other entity). As we are looking from "Inside the VM" and not from "Inside the Network", that needs to be made clear. b) How to perceive TaaS: In the section "Proposed Changes" Taas has been compared with a Core Neutron Plugin ( L3-Router) and a plugin which has emerged out of Neutron ( Neutron LBaaS). This might cause confusion to the reviewers. It would be better that we decide how we would like to demonstrate TaaS: - Is it a plugin which can be integrated with the Neutron Core - Or is it an extension of the Core Neutron Services which can be used by selected users Based on the decision, we can modify the explanation to make the spec a bit more streamed. c) Device Owner for TaaS: - If Tap Service creates a "destination" port, the port would have a device owner of the format of "network:tap" - If the "destination" port is now connected to a VM and the VM is booted up, nova changes the owner to "compute:nova" # Is there any impact of the change of the device_owner # If there is an impact, should there be a change in nova so that the device_owner is not modified # When in the future, TaaS supports user providing an "already created port" should the device owner be checked and modified? d) Outcome of Deleting the VM where TaaS operates Following might be added to the Spec: 1. Deletion of the VM (and port attched to it) from which we were mirroring (source of the mirror): In this case we would do a cascade delete of the 'Tap_Flow' instances that were associated with the port that was deleted. 2. Deletion of the VM (and port attched to it) to which we were mirroring (Destination of the mirror): In this case we would do a cascade delete of the 'Tap_Service' instance that was associated with the port that was deleted. e) Making the API independent of OpenVSwitch As per our last discussion [3], it is better that w esplit our implementation for TaaS, so that # the focus is not limited to OpenVSwitch, which may be a point of concern during review # allow other vendors to create thier own pluggable implementation f) Choice of Tapping before/after Sec Groups Security Groups can filter a lot , and implementing TaaS before or after the SG can impact the overall monitoring. As referenced in [1], we can provide this option as a future course of work, and in the meanwhile specify the option which we are working upon ( Before or After) in the spec, to make it clear. [1]:https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst [2]: https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst [3]: http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt -- 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