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 possible in > > > terms of time and features or if it seems to be just the delusion of an > > > ignorant. > > > Do you think the component should also have the capability to change > > > security-related policies, like load-balancing and firewall rules as to > > > react to identified threats? > > > > > > I would appreciate any insight you could give me about this idea, or any > > > other I could help with instead. > > > > > > Thank you for your attention, > > > > > > Mario > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > -- > > Kevin Benton > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ 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
