Great, welcome to the team Carlos! Look forward to collaborating with you and we’ll see you at this Thursday’s IRC meeting!
Kyle On Feb 17, 2014, at 11:19 AM, Carlos Gonçalves <[email protected]> wrote: > Hi, > > Firstly, I would like to thank you all for your replies! > > I am very much interested in taking some kind of participation on this > subject, especially on service chain. I’m a entry-level guy on Neutron, but > you can count on me to discuss and develop these BPs. Besides BP documents, > I’ve been reading meeting logs and reviewing patches on Gerrit hoping to have > a better understanding on where the group stands as of now. > > My nickname on IRC is (surprise, surprise!) ‘cgoncalves’. > > Thanks, > Carlos Goncalves > > On 17 Feb 2014, at 07:10, Sumit Naiksatam <[email protected]> wrote: > >> Hi, Apologies for chiming in late on this. Yes, we have been >> incubating the service insertion and chaining features [2] for some >> time now. The plan was to have a FW-VPN chain working by Icehouse >> release. Towards that end the first step was to introduce the notion >> of a service insertion context which forms the foundation for the >> service chain resource. The following patch aims to address the >> service insertion context: >> https://review.openstack.org/#/c/62599/ >> >> and we hope to get the above merged into Icehouse. However, it does >> not seem like we will be able to land the service chaining in >> Icehouse. That said we are hoping to introduce WIP patches soon that >> will implement the ideas so far discussed. >> >> We had regular IRC meetings earlier on the topic of "advanced >> services", but we suspended those temporarily so as not to distract >> from the Neutron stabilization and parity work underway in Icehouse. >> We hope to get back to those meetings once the critical bugs and >> features slated for Icehouse are out of the way. >> >> Per your question in the context of the Group Policy work, these two >> features are indeed complementary. As pointed out in this thread, one >> of the options for rendering the Groups Policies is on top of >> elemental Neutron abstractions as service chains expressed in [2]. >> Also as pointed out in another email thread, we will specifically >> touch on this topic in the upcoming Group Policy meetings. >> >> Thanks, >> ~Sumit. >> >> >> >> On Wed, Feb 12, 2014 at 10:21 AM, Stephen Wong <[email protected]> wrote: >>> Hi Carlos, >>> >>> >>> On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gonçalves <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> I've a couple of questions regarding the ongoing work on Neutron Group >>>> Policy proposed in [1]. >>>> >>>> 1. One of the described actions is redirection to a service chain. How do >>>> you see BPs [2] and [3] addressing service chaining? Will this BP implement >>>> its own service chaining mechanism enforcing traffic steering or will it >>>> make use of, and thus depending on, those BPs? >>> >>> >>> We plan to support both specifying Neutron "native" service chain >>> (reference [2] from your email below) as the object to 'redirect' traffic to >>> as well as actually setting an ordered chain of services specified directly >>> via the 'redirect' list. In the latter case we would need the plugins to >>> perform traffic steering across these services. >>> >>> >>>> 2. In the second use case presented in the BP document, "Tired application >>>> with service insertion/chaining", do you consider that the two firewalls >>>> entities can represent the same firewall instance or two running and >>>> independent instances? In case it's a shared instance, how would it support >>>> multiple chains? This is, HTTP(s) traffic from Inet group would be >>>> redirected to the firewall and then passes through the ADC; traffic from >>>> App >>>> group with destination DB group would also be redirected to the very same >>>> firewall instance, although to a different destination group as the chain >>>> differs. >>> >>> >>> We certainly do not restrict users from setting the same firewall >>> instance on two different 'redirect' list - but at this point, since the >>> group-policy project has no plan to perform actual configurations for the >>> services, it is therefore the users' responsibility to set the rules >>> correctly on the firewall instance such that the correct firewall rules will >>> be applied for traffic from group A -> B as well as group C -> D. >>> >>> - Stephen >>> >>>> >>>> >>>> Thanks. >>>> >>>> Cheers, >>>> Carlos Gonçalves >>>> >>>> [1] >>>> https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction >>>> [2] >>>> https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering >>>> [3] >>>> https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
