[openstack-dev] Is the pendulum swinging on PaaS layers?
mordred at inaugust.com
Fri May 19 20:13:16 UTC 2017
On 05/19/2017 01:53 PM, Sean Dague wrote:
> 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.
We also searching of all resources by name-or-id in shade. But it's one
call - GET /images - and then we test to see if the given value matches
the name field or the id field. And there is caching, so the list call
is done once in the session.
The thing I'm the saddest about is the Nova flavor "extra_info" that one
needs to grab for backwards compat but almost never has anything useful
in it. This causes me to make a billion API calls for the initial flavor
list (which is then cached of course) It would be WAY nicer if there was
a GET /flavors/detail that would just get me the whole lot in one go, fwiw.
Dean has a harder time than I do with that one because osc interactions
are lots of process invocations from scratch. We chatted a bit about how
to potentially share caching things in Boston, but not sure we've come
up with more.
> 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.
Couldn't agree more . I think we're getting better at that communication.
We still have a hole, which is that the path from "this is a problem and
here's how I'm working around it" to "there are devs tasked to work on
solving that problem" is a hard one, because while the communication
from those of us doing client-layer stuff with the folks doing the
servers is pretty good - the communication loop with the folks at the
companies who are prioritizing work ... not so much. Look at the number
of people hacking on shade or python-openstackclient or writing
user-facing docs compared to folks adding backend features to the services.
So - yes, I totally agree. But also, we can make and are making a lot of
progress in some areas with tiny crews. That's gonna likely be the state
of the world for a while until we're better able to point our fingers at
the problem and characterize it such that our friends who provide
resources value these problems enough to fund working on them.
More information about the OpenStack-dev