16:01:26 #startmeeting api-sig 16:01:27 heh, just going to start if you weren't around 16:01:27 Meeting started Thu Dec 7 16:01:26 2017 UTC and is due to finish in 60 minutes. The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:30 The meeting name has been set to 'api_sig' 16:01:45 #chair edleafe elmiko dtantsur 16:01:46 Warning: Nick not in channel: elmiko 16:01:47 Current chairs: cdent dtantsur edleafe elmiko 16:01:52 hi gildub 16:01:58 cdent, hi 16:02:02 #link agenda https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda 16:02:24 #topic old biz 16:02:34 #link last meeting’s minutes: http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-11-30-16.01.html 16:02:53 main action item was to get dtantsur fixed up on gerrit, that’s been done 16:03:00 \o/ 16:04:20 #topic new biz 16:04:58 api schema is the topic from the agenda, which I believe gildub raised. I assume you’ve seen the comments that dtantsur and I left on the stub review 16:05:19 #link api schema review https://review.openstack.org/#/c/524467/ 16:06:03 Yes I did. I haven't had time to respond, more likely tomorrow 16:06:29 What would you like to raise here today? 16:06:38 gildub: my initial reaction was that this was feeling SOAPy 16:06:55 gildub: is the goal to have machine-discoverable API calls? 16:08:11 Well its just a place holder as a starting point, as we need guidelines but the core content likely to be in a specs file, 16:09:01 and machine-discoverable API could be one use case 16:11:08 So would these schema be generated, or hand-crafted? 16:11:10 My sense is that we probably need some kind of discussion, likely on the mailing list, about the use cases and potential solutions to those use cases. At this stage it still feels a bit too vague to write a guideline as it’s not clear what is being guided. 16:12:02 Defining the need that would be satisfied is a good first step 16:12:13 edleafe, the API schema already exist, in the form of RST file, used by the documentation generation 16:12:59 cdent, I have tried to have to have that discussion for month in the ML, now isn't a good time to discuss it? 16:13:45 gildub: now is fine too, but there aren’t many people here, just 4 of us 16:13:57 The need is to have a different format for the API schema that already exist in RST format, I have the need, and althouth we don't have lots of consumer present (I any please speak up) 16:13:58 I would guess that if you aren’t get any response on the mailing list then there’s little interest 16:14:12 or no time for people to have interest 16:14:15 gildub: I did an initial investigation of doing a YAML publish from what we have now 16:14:25 (5) 16:14:31 I think it may be possible 16:14:47 but I haven't had a huge amout of time over the last few weeks 16:15:40 cdent, I know that other people are interested, AT&T folks who did the Keynote presentation a Sydney summit are using automation for handling their SDKs 16:15:42 I am *very* reluctant to change how we currently generate the api-ref 16:15:54 mugsie, great, that's good news :) 16:16:08 gildub: yes, but at&t doesn’t show up on the developer list nor in regular contributions as much as maybe they could. until they do, little is going to happen. 16:16:13 it took long enought to get it in use, I think changing is will just mean that it will be ignored 16:16:37 mugsie: yeah, sad but true. 16:16:47 mugsie, I understand, that's fair enough, but I suppose that's okay, just use the other way around then? 16:16:49 gildub: agree with cdent. If there is an interest, then they need to show up to help with the design and eventual work 16:16:58 assuming that some automatic extraction to yaml could happen, what would then be done with it? 16:17:46 cdent, edleafe, when I look at google cloud API, I feel like running away and hide behind a stone!!! 16:18:07 gildub: :) 16:18:43 I feel like running away and hiding behind a stone pretty much all the time 16:19:41 ++ 16:20:01 Should we try to enumerate some of the use cases here, or if we can’t do that shall we move on? 16:20:13 I would prefer to see them in the spec 16:21:25 cdent, edleafe, having the API schema being more consumable opens possibilities, and obviously beside this topics we did get much traction from SDKs consumers on any topics, so that doesn't prove anything, I have the need for this and I have people behind me supporting it 16:21:57 cdent, edleafe, ^ s/we did get/we didn't get/ 16:23:07 given the latency involved in changing the api-ref, I think a productive avenue of exploration would be seeing if there is a way to formalize/structure the extraction of some machine readable from api-ref as it is currently formed. I know you do this already gildub, but I’m not clear to what extent it requires human involvement or tweaking? 16:23:49 mugsie, can you help clarify this ^ 16:23:51 gildub, mugsie is that something the two of you can continue to explore, as time allows? 16:24:21 From what I can tell, we have the entire API in a tree structure in sphinx already when we publish. I think we could take that and write a sphinx publisher that outputs it to yaml / json / $FOOLANG 16:24:39 cdent: yeap, I will comment on the review with details 16:25:12 alright, in that case, perhaps we should move on? 16:25:27 #action mugsie to explain api-ref automation potential 16:25:43 any other new biz? 16:25:49 Fantastic, thank you! 16:26:37 #topic guidelines 16:26:43 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:27:12 only recent activity is gildub’s new review, discussed above: 16:27:16 #link schema stub https://review.openstack.org/#/c/524467/ 16:27:26 everything else is in the same state as last week 16:27:42 anyone have anything to say about guidelines? 16:27:48 not I 16:28:20 * dtantsur is busy with OMG URGENT stuff, so he cannot get to writing a microversions guideline he promised 16:28:56 noted 16:28:57 #topic bug review 16:28:58 #link https://bugs.launchpad.net/openstack-api-wg 16:29:01 no new bugs 16:29:06 I wonder about discover-ability 16:29:16 https://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html 16:30:05 how to progress on this one, doesn't seem like there is anything in the PRs 16:30:24 cdent, sorry I missed the boat! 16:30:43 gildub: is okay. there is a pending review for discoverability: https://review.openstack.org/#/c/459405/ 16:31:11 that’s part of a stack of things that mordred is working on for both service and version discovery 16:32:05 cdent, true but this is more about version and the discovery real topic is not touched: https://review.openstack.org/#/c/459405/28/guidelines/discoverability.rst 16:32:35 cdent, not *really* touched ;) 16:33:12 gildub: do none of these address your concerns? https://review.openstack.org/#/q/project:openstack/api-wg+owner:%22Monty+Taylor+%253Cmordred%2540inaugust.com%253E%22 what’s missing? 16:35:11 cdent, not on how to discover an API consistently, did I miss something? I guess that's a *big* and *old* topic which requires *more* discussion 16:35:49 cdent, I know this has been evoked before in PTGs 16:36:09 gildub: I’m not sure what you mean in this case by “discover an API”? 16:38:25 cdent, what the guideline document says: "This topic document serves to provide guidance on how to have a public REST API expose the URIs and resources to end users in a machine-readable way" 16:38:45 gildub: if there’s something missing from that stack of stuff, and it is not covered by the schema concept, please feel free to either make a stub guideline explaining what it is, or make a bug 16:39:08 gildub: yeah, and the service catalog and the root version document provide the first and second entry points to that. are you after the third? 16:41:01 #topic weekly newsletter 16:41:01 #link https://etherpad.openstack.org/p/api-sig-newsletter 16:41:20 we were going to make dtantsur do this, but I reckon since he’s OMG URGENT that might be unfair 16:41:22 cdent, I suppose I'm after the overall guidance and also the 3rd, I'll add comment to the PR 16:41:33 cdent: yep, and I have to run soon after.. 16:41:46 edleafe: you wanna, or is it on me? 16:42:22 elmiko's not here, so I volunteer him :) 16:42:32 lol, fair 16:42:41 I think you did last week, so I guess I'll do it 16:43:33 thanks edleafe, I’ll be around for a proof 16:43:55 ok, I'm finishing up something, so it'll be a few minutes 16:44:28 shall we close it up then? thanks for coming gildub, I feel like we weren’t really able to address your concerns, but I hope it gets some brain cells moving in more people. 16:45:03 cdent, thanks, well we are progressing since we are discussing it, I guess :D) 16:45:34 cdent, oh by the way what about adding another meeting session? It's 3:45 am down under right now! 16:46:10 gildub: I was waiting to see if there was more response to the mailing list thread that you and elmko were participating in and there’s not been 16:46:10 cdent, and I woke up a bit by accident, I was like "good timing, the API SIG is now!" 16:46:26 gildub: :) 16:46:46 I think the inevitable outcome is simply this: If we want to be inclusive we need to use email more and if we’re not getting participation in email, then that’s a signal. 16:47:18 cdent, makes sense 16:47:47 gildub: cdent: maybe try a meeting at 2200 UTC? 16:47:47 cdent, but I usually don't get much traction on emails, maybe it's just me :( 16:48:12 cdent: that's too late for you, but I could make it 16:48:24 If people do want to try another meeting, that’s fine with me, but it’s unlikely I’ll show up, which is fine. 16:49:02 gildub: would 2200UTC work for aussies? 16:49:13 cdent, better for me, then I can push *hard* the machine readable features 16:49:24 :) 16:49:26 edleafe, yes 16:50:06 #action edleafe to investigate open meeting times at 2200UTC 16:50:13 I'll see what I can do 16:50:20 edleafe, thanks 16:50:50 23:00 is a bit brutal for me, but I guess we can alternate :) 16:51:30 dtantsur: I was thinking in addition to this time 16:51:38 just to see if there is interest 16:51:55 ++ 16:52:09 seems reasonable 16:52:56 dtantsur, sorry the only other option is another meeting but I'm not sure how we reconcile the two meeting, some project have that to be able to cover the planet TZs 16:53:36 yeah, we had two meeting in ironic. did not work well, but milage may vary 16:53:37 Seems there are not that many people involved in Asia/Pacific... 16:54:00 gildub: well, if we get enough APAC interest, we may be able to get a core out of it to run that meeting 16:54:23 edleafe, ok, let's see 16:55:05 ok, are we done? 16:55:09 On that note optimism, let’s close. Thanks everyone for coming 16:55:22 cdent, edleafe, dtantsur, mugsie, thank you for your time & help 16:55:31 #endmeeting