Hi Mario,
Salvatore and Kevin perfectly expressed what I think.
I’d follow his advice, and look on how the advanced services [1] [2]
integrate with neutron,
and build a POC. If the POC looks good it could be a good start point to build
community
around and go on with the development.
[1] https://github.com/openstack/neutron-lbaas
[2] https://github.com/openstack/neutron-fwaas
Miguel Ángel Ajo
On Sunday, 18 de January de 2015 at 13:42, Salvatore Orlando wrote:
Hello Mario,
IDS surely is an interesting topic for OpenStack integration. I think there
might be users out there which could be interested in having this capability
in OpenStack networks.
As Kevin said, we are moving towards a model where it becomes easier for
developers to add such capabilities in the form of service plugins - you
should be able to develop everything you need in a separate repository and
still integrate it with Neutron.
According to what you wrote you have just a bit more than 100 hours to spend
on this project. What can be achieved in this timeframe really depends on
one's skills, but I believe it could be enough to provide some sort of
Proof-of-Concept. However, this time won't be enough at all if you also aim
to seek feedback on your proposal, build a consensus and a developer
community around it. Unsurprisingly these aspects, albeit not technically
challenging, take an awful lot more time than coding!
Therefore the only advice I have here is that you should focus on achieving
your real goal, which is graduate with the highest possible marks! Then, if
from your thesis there will be something to gain for the OpenStack community,
that would be awesome. With a PoC implementation and perhaps some time on
your hands, you can then be able to work with the community to transform your
masters' project into an OpenStack project and avoid it becomes a bitrotting
shelved piece of code.
Salvatore
On 18 January 2015 at 10:45, Kevin Benton blak...@gmail.com
(mailto:blak...@gmail.com) wrote:
Hi Mario,
There is currently a large backlog of network-related features that many
people want to develop for Neutron. The model of adding them all to the
main neutron codebase has failed to keep up. Due to this, all of the
advanced services (LBaaS, FWaaS, etc) are being separated into their own
repositories. The main Neutron repo will only be for establishing L2/L3
connectivity and providing a framework for other networking services to
build on. You can read more about it in the advanced services split
blueprint.[1]
Based on what you've described, it sounds like you would be developing an
IDS service plugin with a driver/plugin framework for different vendors.
For an initial proof of concept, you could do it in github to get started
quickly or you can also request a new stackforge repo for it. The benefit
of stackforge is that you get the OpenStack testing infrastructure and
integration with its gerrit system so other OpenStack developers don't have
to switch code review workflows to contribute.
To gauge interest, I would try emailing the OpenStack users list. It
doesn't matter if developers are interested if nobody ever wants to
actually try it out.
1. https://blueprints.launchpad.net/neutron/+spec/services-split
Cheers,
Kevin Benton
On Fri, Jan 16, 2015 at 2:32 PM, Mario Tejedor González
m.tejedor-gonza...@mycit.ie (mailto:m.tejedor-gonza...@mycit.ie) wrote:
Hello, Neutron developers.
My name is Mario and I am a Masters student in Networking and Security.
I am considering the possibility of integrating IDS technology to Neutron
as part of my Masters project.
As there are many flavors of open ID[P]S out there and those might follow
different philosophies, my approach would be developing a Neutron plugin
that might cover IDS integration as a service and also a driver (or more,
depending on time constraints) to cover the specifics of an IDS.
Following the nature of Neutron and OpenStack projects these drivers
would be developed for Free and Open Software IDSs and the plugin would
be as vendor-agnostic as possible. In order to achieve that the plugin
would have to deal with the need for logging and alerting.
The time window I have for the development of this project goes from
February to the end of June and I would be able to allocate around 5h a
week to it.
Now, I would like to know your opinion on this idea, given that you know
the project inside out and you are the ones making it happen day after
day.
Do you think there is usefulness on bringing that functionality inside
the Neutron project (as a plugin)? I'd prefer do something that
contributes to it rather than a one-shot piece of software that will be
stored on a shelf.
I'd like to know if you think that what I am proposing is