On 05/19/2017 03:13 PM, Monty Taylor wrote:
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 <s...@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_
complicated).
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.
Quick follow up on this one.
It was "extra_specs" I was thinking about - not "extra_info"
It used to be in the flavor as part of an extension (with a longer name)
- we fetch them in shade for backwards compat with the past when they
were just there. However, I've also learned from a follow up in IRC that
these aren't really things that were intended for me.
So I'll re-frame this point slightly ...
As a user it's often quite difficult to tell what general intent is
related to use of resources - whether they are intended for general
users, or whether they are intended for admins. I guess a lot, and
sometimes I get it right, and sometimes I don't. I know, I know - policy
makes it so that different cloud deployers can have _vastly_ different
opinions on this. But a clear intent from us (greatly helped, btw, by
putting default policy in code) of "this call, this resource, this field
is intended for normal users, but this one is intended for admin users"
would have certainly helped me many times in the past.
Thanks for the IRC chat!
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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
