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].
[1] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
[2] https://review.openstack.org/#/c/186663/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
