<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 16/03/18 19:55, Chris Dent wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
Meta: When responding to lists, please do not cc individuals, just
<br>
repond to the list. Thanks, response within. <br>
<br>
</blockquote>
<br>
+1 <br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">On
Fri, 16 Mar 2018, Gilles Dubreuil wrote: <br>
<br>
<blockquote type="cite">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]. <br>
<br>
Unfortunately until a new or either a second meeting time slot
has been allocated, inconveniently for everyone, have to be
done by emails. <br>
</blockquote>
<br>
I'm sorry that the meeting time is excluding you and others, but
our <br>
efforts to have either a second meeting or to change the time have
<br>
met with limited response (except from you). <br>
<br>
In any case, the meeting are designed to be checkpoints where we <br>
resolve stuck questions and checkpoint where we are on things. It
is <br>
better that most of the work be done in emails and on reviews as <br>
that's the most inclusive, and is less dependent on time-related <br>
variables. <br>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
So moving the discussion about schemas here is the right thing and
<br>
the fact that it hasn't happened (until now) is the reason for
what <br>
appears to be a rather lukewarm reception from the people writing
<br>
the API-SIG newsletter: if there's no traffic on either the gerrit
<br>
review or here in email then there's no evidence of demand. You're
<br>
asserting here that there is; that's great. <br>
</blockquote>
<br>
Yes, and some of those believers are to either jump-on this thread
or add comment to related reviews in order to confirm this.<br>
Of course one cannot expect them to be active participants as I'm
delegated to be the interface for this feature.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<blockquote type="cite">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? <br>
It seems unfair to decide not to move forward and ignore the
request because the others people interested are not
participating at this level. <br>
</blockquote>
<br>
In a world of limited resources we can't impose work on people.
The <br>
SIG is designed to be a place where people can come to make
progress <br>
on API-related issues. If people don't show up, progress can't be
<br>
made. Showing up doesn't have to mean show up at an IRC meeting.
In <br>
fact I very much hope that it never means that. Instead it means <br>
writing things (like your email message) and seeking out <br>
collaborators to push your idea(s) forward. <br>
</blockquote>
<br>
This comforts me about more automation to help ;)<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<blockquote type="cite">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. <br>
</blockquote>
<br>
Can some of those "us" show up on the mailing list, the gerrit <br>
reviews, and prototype work that Graham has done? <br>
</blockquote>
<br>
Yes absolutely, as I just mentioned above.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<blockquote type="cite">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. <br>
</blockquote>
<br>
Them too. <br>
</blockquote>
<br>
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...<br>
I'll poke the second ones.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<blockquote type="cite">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. <br>
<br>
Finally how can we dare say no to more automation? Unless of
course, only artisan work done by real hipster is allowed ;) <br>
</blockquote>
<br>
Nobody is saying no to automation (as far as I'm aware). Some
people <br>
(e.g., me, but not just me) are saying "unless there's an active <br>
community to do this work and actively publish about it and the <br>
related use cases that drive it it's impossible to make it a <br>
priority". Some other people (also me, but not just me) are also <br>
saying "schematizing API client generation is not my favorite
thing" <br>
but that's just a personal opinion and essentially meaningless <br>
because yet other people are saying "I love API schema!". <br>
<br>
What's missing, though, is continuous enagement on producing <br>
children of that love. <br>
</blockquote>
<br>
Well I believe, maybe because I kind of belong to the second group,
that the whole API definition is upside-down.<br>
If we had API schema from day one we would have more children of
love and many many more grand children of Openstack users.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<blockquote type="cite">
<blockquote type="cite">Furthermore, API-Schema will be
problematic for services that use </blockquote>
microversions. If you have some insight or opinions on this,
please add your comments to that review. <br>
<br>
I understand microversion standardization (OpenAPI) has not
happened yet or if it ever does but that shouldn't preclude
making progress. <br>
</blockquote>
<br>
Of course, but who are you expecting to make that progress? The <br>
API-SIGs statement of "not something we're likely to pursue as a <br>
part of guidance" is about apparent unavailability of interested <br>
people. If that changes then the guidance situation probably
changes <br>
too. <br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
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. <br>
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.<br>
Maybe that's what I kind of expect here, to get support to do so.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
But not writing guiadance is different from provide a place to
talk <br>
about it. That's what a SIG is for. Think of it as a room with <br>
coffee and snacks where it is safe to talk about anything related
to <br>
APIs. And that room exists in email just as much as it does in IRC
<br>
and at the PTG. Ideally it exists _most_ in email. <br>
<br>
<blockquote type="cite">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]). <br>
</blockquote>
<br>
What do you see as the current roadblocks preventing this work
from <br>
continuing to make progress? <br>
</blockquote>
<br>
<br>
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. <br>
<br>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.1803160833200.19209@cdent-m01.vmware.com">
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>