Open Stack

Ihar,

The Service Group API will be added to FWaaS only and remain experimental in M. If the community finds it useful for other areas it can be added to Neutron core once it is matures. I think incubating it inside FWaaS will give us the velocity to iterate quickly and once it matures a strong API for adoption in the wider Neutron.

On the other hand if classifiers mature more quickly/provide the same functionality more elegantly we can quickly pivot to that. Since we are trying to address an immediate need I would like to experiment with Service Groups inside FWaaS first and then use that to shape the classifier API discussion. Also, as Sean suggested, we might use the classifier data models under the hood — so despite being a different API at first we might arrive at the same shared implementation…

Thanks,
German



On 11/13/15, 1:12 AM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:

>Paul Carver <pcarver at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev