[openstack-dev] Is the pendulum swinging on PaaS layers?
sean at dague.net
Fri May 19 18:53:26 UTC 2017
On 05/19/2017 02:34 PM, Dean Troyer wrote:
> On Fri, May 19, 2017 at 1:04 PM, Sean Dague <sean at dague.net> wrote:
>> These should be used as ways to experiment with the kinds of interfaces
>> we want cheaply, then take them back into services (which is a more
>> expensive process involving compatibility stories, deeper documentation,
>> performance implications, and the like), not an end game on their own.
> I totally agree here. But I also see the rate of progress for many
> and varied reasons, and want to make users lives easier now.
> Have any of the lessons already learned from Shade or OSC made it into
> services yet? I think a few may have, "get me a network" being the
> obvious one. But that still took a lot of work (granted that one _is_
Doing hard things is hard. I don't expect changing APIs to be easy at
this level of deployedness of OpenStack.
>> You can get the behavior. It also has other behaviors. I'm not sure any
>> user has actually argued for "please make me do more rest calls to
>> create a server".
> Maybe not in those words, but "give me the tools to do what I need"
> has been heard often. Sometimes those tools are composable
> primitives, sometimes they are helpful opinionated interfaces. I've
> already done the helpful opinionated stuff in OSC here (accept flavor
> and image names when the non-unique names _do_ identify a single
> result). Having that control lets me give the user more options in
> handling edge cases.
Sure, it does. The fact that it makes 3 API calls every time when doing
flavors by name (404 on the name, list all flavors, local search, get
the flavor by real id) on mostly read only data (without any caching) is
the kind of problem that rises from "just fix it in an upper layer". So
it does provide an experience at a cost.
All for new and better experiences. I think that's great. Where I think
we want to be really careful is deciding the path to creating better
experiences is by not engaging with the services and just writing around
it. That feedback has to come back. Those reasons have to come back, and
we need to roll sensible improvements back into base services.
If you want to go fast, go alone, if you want to go far, go together.
More information about the OpenStack-dev