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.
__________________________________________________________________________ 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
