Open Stack

On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote:
>
> 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.

I don't think I disagree at all. But we don't have a classifier API in 
neutron core (unless we consider security groups to be it) and I don't 
think anyone is saying that the classifier in networking-sfc should be 
merged straight into core as-is. In fact I think we're saying exactly 
the opposite, that *a* classifier will sit in networking-sfc, outside of 
core neutron, until *some* classifier is merged into core neutron.

The point of networking-sfc isn't the classifier. A classifier is simply 
a prerequisite. So by all means let's work on defining and merging into 
core neutron a classifier that we can consider non-experimental and 
stable for all features to share and depend on, but we don't want SFC to 
be non-functional while we wait for that to happen. We can call the 
networking-sfc classifier experimental a slap a warning on that it'll be 
replaced with the core neutron classifier once such a thing has been 
implemented.