On 16/03/18 19:55, Chris Dent wrote:
Meta: When responding to lists, please do not cc individuals, just
repond to the list. Thanks, response within.
+1
On Fri, 16 Mar 2018, Gilles Dubreuil wrote:
In order to continue and progress on the API Schema guideline [1] as
mentioned in [2] to make APIs more machine-discoverable and also
discussed during [3].
Unfortunately until a new or either a second meeting time slot has
been allocated, inconveniently for everyone, have to be done by emails.
I'm sorry that the meeting time is excluding you and others, but our
efforts to have either a second meeting or to change the time have
met with limited response (except from you).
In any case, the meeting are designed to be checkpoints where we
resolve stuck questions and checkpoint where we are on things. It is
better that most of the work be done in emails and on reviews as
that's the most inclusive, and is less dependent on time-related
variables.
I agree in general most of our work can be done "off-line" meanwhile
there are times were interaction is preferable especially in early
phases of conception in order to provide appropriate momentum.
So moving the discussion about schemas here is the right thing and
the fact that it hasn't happened (until now) is the reason for what
appears to be a rather lukewarm reception from the people writing
the API-SIG newsletter: if there's no traffic on either the gerrit
review or here in email then there's no evidence of demand. You're
asserting here that there is; that's great.
Yes, and some of those believers are to either jump-on this thread or
add comment to related reviews in order to confirm this.
Of course one cannot expect them to be active participants as I'm
delegated to be the interface for this feature.
Of course new features have to be decided (voted) by the community
but how does that work when there are not enough people voting in?
It seems unfair to decide not to move forward and ignore the request
because the others people interested are not participating at this
level.
In a world of limited resources we can't impose work on people. The
SIG is designed to be a place where people can come to make progress
on API-related issues. If people don't show up, progress can't be
made. Showing up doesn't have to mean show up at an IRC meeting. In
fact I very much hope that it never means that. Instead it means
writing things (like your email message) and seeking out
collaborators to push your idea(s) forward.
This comforts me about more automation to help ;)
It's very important to consider the fact "I" am representing more
than just myself but an Openstack integration team, whose members are
supporting me, and our work impacts others teams involved in their
open source product consuming OpenStack. I'm sorry if I haven't made
this more clear from the beginning, I guess I'm still learning on the
particiaption process. So from now on, I'm going to use "us" instead.
Can some of those "us" show up on the mailing list, the gerrit
reviews, and prototype work that Graham has done?
Yes absolutely, as I just mentioned above.
Also from discussions with other developers from AT&T (OpenStack
summit in Sydney) and SAP (Misty project) who are already using
automation to consume APIs, this is really needed.
Them too.
For the first ones, I've tried without success (tweeter), unfortunately
I don't have their email addresses, let me ask Openstack Organizers if
they can pass it along...
I'll poke the second ones.
I've also mentioned the now known fact that no SDK has full time
resources to maintain it (which was the initial trigger for us) more
automation is the only sustainable way to continue the journey.
Finally how can we dare say no to more automation? Unless of course,
only artisan work done by real hipster is allowed ;)
Nobody is saying no to automation (as far as I'm aware). Some people
(e.g., me, but not just me) are saying "unless there's an active
community to do this work and actively publish about it and the
related use cases that drive it it's impossible to make it a
priority". Some other people (also me, but not just me) are also
saying "schematizing API client generation is not my favorite thing"
but that's just a personal opinion and essentially meaningless
because yet other people are saying "I love API schema!".
What's missing, though, is continuous enagement on producing
children of that love.
Well I believe, maybe because I kind of belong to the second group, that
the whole API definition is upside-down.
If we had API schema from day one we would have more children of love
and many many more grand children of Openstack users.
Furthermore, API-Schema will be problematic for services that use
microversions. If you have some insight or opinions on this, please
add your comments to that review.
I understand microversion standardization (OpenAPI) has not happened
yet or if it ever does but that shouldn't preclude making progress.
Of course, but who are you expecting to make that progress? The
API-SIGs statement of "not something we're likely to pursue as a
part of guidance" is about apparent unavailability of interested
people. If that changes then the guidance situation probably changes
too.
This a question I've been struggling about a lot. What's the API SIG
purpose and how effective it can be in driving changes.
I understand the history of OpenStack has been very pragmatically driven
from all its projects and even more strongly from some 'core' projects
such as Nova.
Meanwhile it doesn't preclude OpenStack overall project to benefit from
having needs driven from a user level requirements. As far as know,
there are no other structure, whether project or SIG/WG that can
currently tackle this better than the API SIG.
Yes, going across the projects is daunting but I believe that's the
challenge to lead and share among all projects that OpenStack needs it.
Maybe that's what I kind of expect here, to get support to do so.
But not writing guiadance is different from provide a place to talk
about it. That's what a SIG is for. Think of it as a room with
coffee and snacks where it is safe to talk about anything related to
APIs. And that room exists in email just as much as it does in IRC
and at the PTG. Ideally it exists _most_ in email.
So summarize and clarify, we are talking about SDK being able to
build their interface to Openstack APIs in an automated way but
statically from API Schema generated by every project. Such API
Schema is already built in memory during API reference documentation
generation and could be saved in JSON format (for instance) (see [5]).
What do you see as the current roadblocks preventing this work from
continuing to make progress?
Once we've obtained clear evidence from others of such need and assuming
we have support of the committee then I suppose Graham's PR will move
forward before we add guidance for API schema use.
__________________________________________________________________________
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
