Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180320/7542e55f/attachment.html>