Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/6cfd4f3b/attachment.html>