Hi Carlos, The provider mechanism is currently under discussion in advanced service group. However, your use-case of chaining non-neutron service has not been considered in the proposal. If you believe it is an important feature, please definitely be vocal, even better to have a proposal. :-)
3- For the service chain creation, I am sure there are good reasons for >> requiring a specific provider for a given chain of services but wouldn't it >> be possible to have a generic "chain" provider which would instantiate each >> service in the chain using the required provider for each service (e.g., >> firewall or loadbalancer service) and with setting the insertion contexts >> for each service such that the chain gets constructed as well? I am sure I >> am ignoring some practical requirements but is it worth rethinking the >> current approach? >> >> Service Chaining often means a form of traffic steering. Depending on how > the steering is done, the capabilities of different providers differ. > Different provider may define different context of individual service in > the chain. For example, a bump-in-the-wire service can be inserted as a > virtual wire or L3 next hop. So it will be hard to define a "generic" chain > provider. > > > I'm partially with Mohammad on this. > > For what I've understood from the service chaining proposal, there would > be different service chain provider implementations with each one > restricting to a statically defined and limited number of services for > chaining (please correct me if I'm mistaken). This is, and taking the > "Firewall-VPN-ref-Chain" service chain provider from the document as > example, users would be limited to creating chains "firewall -> VPN" (and > I'm not even considering the restrictiveness of service providers) but not > "VPN -> firewall", or introducing a LB in the middle. > > > My rough understanding on chaining, in a broad term, would be to firstly > support generic L2/L3 chaining, and not restricting to Neutron services > (FWaaS, LBaaS, VPNaaS) if that is the case, but should also be valid for > them as they can be reached via network ports as well. > > Last week during the advanced services meeting I presented the following > use case. DPI (Deep Packet Inspection) is an example of a absent Neutron > service as of now. Users wanting to run a DPI instance in OpenStack would > have to create a virtual machine and run it there which is fine. Now, in > case they want to filter inbound traffic from a (public) network, traffic > should be steered first to the VM running the DPI and then to the final > destination. Currently in OpenStack it is not possible to configure this > and I don't see how in the proposed BP it would be. It was given the > example of a DPI, but it can be virtually any service type and service > implementation. Sure users wouldn't get all the fancy APIs OpenStack > providers instantiate and configure services. > > -- Kanzhe Jiang MTS at BigSwitch
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
