Open Stack

Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:

> Agree with Paul and Louis. The networking-sfc repo should be preserved to  
> support the service function chain functionality. Flow classifier is just  
> needed to specify what flows will go through the service port chain.
>
> The flow classifier API is designed as a separate plugin which is  
> independent of the port chain plugin. We will support the effort of  
> evolving it to a common service classifier API and moving it out of the  
> networking-sfc repo when the time comes.

The problem with that kind of thinking is that TC is needed for other  
features beyond sfc, some of them with strict compatibility requirements  
(like the new fwaas API; or security groups). Once we adopt some API for  
those features, we can’t just drop their support, saying we still iterate  
on it. I am all for being more flexible and not get in the backwards  
compatible van if we are really explicit that those APIs based on new TC  
are not supported whatsoever (I know fwaas had that EXPERIMENTAL tag  
throughout its whole history and lived with that; but I am not sure it  
helped the project adoption; that said, for new projects with no binding  
guarantees to users like SFC it may be a burden to consider this API  
stable).

All I am saying is that IF we merge some classifier API into neutron core  
and start using it for core, non-experimental, features, we cannot later  
move to some newer version of this API [that you will iterate on] without  
leaving a huge pile of compatibility code that would not exist in the first  
place if only we thought about proper API in advance. If that’s what you  
envision, fine; but I believe it will make adoption of the ‘evolving’ API a  
lot slower than it could otherwise be.

Are experimental features the only features we see adopt the TC API in the  
near future?

Ihar