Paul Carver <pcar...@paulcarver.us> wrote:
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.
That’s why I raised service groups spec in this thread: it seems it’s
planned to be added into core, with all compatibility guarantees; and was
planned for adoption for the new fwaas API (as per summit sessions). At
least I haven’t found anything in their spec that would suggest it’s
experimental.
It may mean that at the moment when you arrive to some classifier API that
you can claim the best we can get, there can be a rival classifier API in
the core tree already.
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
