[openstack-dev] [Neutron][SFC]The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

Paul Carver pcarver at paulcarver.us
Tue Jul 28 02:12:15 UTC 2015

On 7/27/2015 4:49 PM, Sean M. Collins wrote:

> I think when the API is too complex, where python-neutronclient is
> expected to create a better UX, that means that the API itself may need
> some further thinking and simplification. I think you are right however,
> that "Get me a network" is the first case where we've recognized that
> the workflow to create a tenant network and have internet connectivity
> is quite involved, and that there needs to be some more automation of
> the different steps.

I don't think it's a matter of expecting python-neutronclient to provide 
a better UX for the full SFC API. It's more a matter of two different 
classes of user. One class of user has some fairly complex use cases 
that can't be satisfied with a hard coded "one true logic" behind a 
simple "do what I want" API. Another class of user doesn't need all that 
complexity and would like a single API call that does exactly the one 
use case they need without the flexibility of handling all the similar 
but not identical use cases.

More input on ways to simplify the API [1] without reducing 
functionality is welcome, but that wasn't what my question was about.

My question was, if there's one particular use case that's especially 
common, but it's essentially just a single use case out of a collection 
of similar use cases, is it reasonable to create an API and/or CLI 
"shortcut" that allows people who don't want or need the full range of 
use case to just get their common one?

P.S. I'm not offering any opinion on whether [2] is or is not in fact 
common. I'm just saying that [2] appears to be a subset of [1] but [2] 
isn't sufficient to meet the needs of people who need [1]. Rather than 
implementing both [1] and [2] independently or forcing people who want 
[2] to use [1], I'm saying that it might be nice if we could provide 
something approximately equivalent to [2] using the implementation 
mechanics of [1].

[2] https://review.openstack.org/#/c/186663/

More information about the OpenStack-dev mailing list