On 2/24/2015 6:47 PM, Kevin Benton wrote:
More seriously, have you considered starting a tap-as-a-service project on stackforge now that the services split has established a framework for advanced services? Uploading the code you are using to do it is a great way to get people motivated to try it, propose new features, critique it, etc. If you can't upload it because your approach would be proprietary, then would upstream support even be relevant?
Right now we haven't written any code, but my concern is really more about standardizing the API. We're currently weighing two categories of options. One is to evaluate a number of open and closed source SDN software as plugins to Neutron. I'm not going to list names, but the candidates are represented in the plugins and ml2 subdirectories of Neutron. Many of these provide tap/mirror functionality, but since there's no standard Neutron API they we would be coding to a vendor specific API and have to call multiple different APIs to do the same thing if we deploy different ones in different locations over time.
The other option that we've considered is to extend a piece of software we've written that currently has nothing to do with tap/mirror but does perform some OvS flow modifications. If we went with this route we certainly would consider open sourcing it, but right now this is the less likely plan B.
It actually doesn't matter to me very much whether Neutron implements the tap functionality, but I'd really like to see a standard API call that the various SDN vendors could get behind. Right now it's possible to make Neutron API calls to manipulate networks, ports, and subnets and expect that they will function essentially the same way regardless of the underlying implementation from a variety of hardware and software vendors. But if we want to mirror a vSwitch port to an analyzer we have a myriad of vendor specific API calls that are entirely dependent on the underlying software and/or hardware beneath Neutron.
__________________________________________________________________________ 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
