16:00:51 #startmeeting api sig 16:00:52 Meeting started Thu May 3 16:00:51 2018 UTC and is due to finish in 60 minutes. The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:56 The meeting name has been set to 'api_sig' 16:01:00 #chair cdent elmiko edleafe dtantsur 16:01:01 Warning: Nick not in channel: cdent 16:01:02 Warning: Nick not in channel: dtantsur 16:01:03 Current chairs: cdent dtantsur edleafe elmiko 16:01:31 o/ 16:01:44 * dtantsur sorry, dragged into a meeting that can be a short email exchange 16:01:49 no worries 16:01:53 might just be you and me 16:02:21 i'll give it a minute or two to see if edleafe or cdent is around 16:02:25 Sorry, lost track of time 16:02:29 no worries 16:02:38 #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda 16:02:44 i don't see cdent around 16:02:51 #topic previous meeting action items 16:02:58 #link http://eavesdrop.openstack.org/meetings/api_sig/2018/ 16:03:06 did we have any actions last time? 16:03:21 BTW, cdent is on holiday this week 16:03:23 survey say, no 16:03:26 ahh, cool! 16:03:38 #topic open mic and ongoing or new biz 16:03:52 so, i added the graphql topic 16:03:57 #link http://lists.openstack.org/pipermail/openstack-dev/2018-April/129987.html 16:04:03 that's the start of the email thread 16:04:16 mainly, i just added it to get opinions from the wider sig 16:04:37 https://twitter.com/sarahmei/status/991878504391229440 16:04:42 either of you have any thoughts about what Gilles is proposing, and using graphql in openstack in general 16:04:55 I'm skeptical 16:05:17 it seems to be one of that hype things To Solve ALL The Problems, that may be difficult in reality 16:05:22 i don't know a ton about graphql, would either of you be willing to write something for the list replying to Gilles? 16:05:39 I've only looked at GraphQL a bit, and share dtantsur's skepticism 16:05:42 i think it's a huge amount of work to propose that openstack shift to graphql, even if it's a long term thing 16:06:10 IMO, it would be best attempted by a separate, dedicated group first 16:06:16 well, I can respond something among the lines of "Which terrible problems with REST are we going to solve by taking such a huge effort?" 16:06:29 And if they achieve the success they envision, we could then make it standard 16:06:40 edleafe: that sounds way too reasonable XD 16:06:50 If it fails to achieve that, well, we haven't derailed the other teams 16:06:56 but, maybe Gilles and others who are interested would be willing to take on that work 16:07:02 right 16:07:11 I guess a prototype of some share of, say, nova API would be interesting 16:07:13 IOW, I agree with the tweet 16:07:32 i don't feel i know enough to agree with the tweet 16:08:08 Every few years something comes along that promises to solve everyone's problems 16:08:17 it seems like there is a desire for not only the schema side of things but perhaps the functionality as well. i've just been following that thread, and it seems like there are at least 2 ppl who are excited by the notion 16:08:22 It *does* make the 80% super-easy, so people get excited 16:08:39 Then they try to implement the 20%, and get bogged down 16:08:50 this ^^^ 16:09:01 they end up spending way more time on the 20% than they did previously on the 100% 16:09:05 REST is also great when you implement CRUD 16:09:41 So if I sound skeptical, that's because I am. :) 16:10:05 But I'd really like to keep an open mind. Maybe this time it will work as advertised! 16:10:45 So let's keep our skepticism to a minimum, and encourage Gilles to get a team together to tackle a single API to start 16:10:46 ok, well i think we should at least respond on list 16:10:55 yeah, i like that edleafe 16:11:25 ok, moving along 16:11:31 any other open biz topics? 16:11:51 #action edleafe to respond to the GraphGL thread 16:11:59 thanks edleafe ! 16:12:13 i suppose we should at least mention the bof session too 16:12:14 #undo 16:12:15 Removing item from minutes: #action edleafe to respond to the GraphGL thread 16:12:19 #action edleafe to respond to the GraphQL thread 16:12:35 Yeah, I was going to bring that up 16:12:44 cool 16:13:04 Did either of you read my reply to Gilles as being dismissive? 16:13:20 Once I re-read it, I could see how he might have interpreted it that way 16:13:31 i thought it could be taken a little snarky, for sure 16:13:51 elmiko: ok, thanks for the reality check 16:13:53 I didn't - but then I know you well 16:14:02 right, same here mordred 16:14:09 if you knew me well, you'd assume snark 16:14:15 XD 16:14:26 yah - but not dismissiveness through snark - just snark :) 16:14:29 i knew you didn't mean ill, but i could see how it could be taken wrong 16:14:34 fwiw, I think neutron would be an excellent trial balloon candidate 16:14:37 mordred: ah, that makes sense :) 16:14:44 mordred: for graphql? 16:14:50 tbh your response did not sound bad to me 16:14:53 the number of api calls needed to essentially do joins client side is usually rather painful 16:14:54 mordred: better for what reasons? 16:14:56 edleafe: yup 16:15:11 answered before I asked 16:15:52 the api basically is exposing individual db tables and the user has to do client-side linking of things ... that said - what would REALLY be useful is a consolidated graphql interface 16:16:08 ok, so for the forum session, should we make a simple paragraph for the bof just saying come talk about api sig stuff. open agenda and all ? 16:16:18 because what I REALLY need to do is "please give me the port id for the port associated with this server that's on this netwrk" 16:16:37 so would the people developing this graphql interface need to be intimately familiar with Neutron? 16:16:47 edleafe: I don;t think so, no 16:16:53 ok, great 16:17:14 Then let's propose that to Gilles et. al. 16:17:15 developing the graphql would be about exposing the 'tables' into the model - which is prettymuch already done in the existing rest api and/or sqlalchemy layer 16:17:17 ++ 16:17:47 mordred: would you mind adding these thoughts to the email thread? 16:19:09 ++ 16:20:20 elmiko: sure thing! 16:20:35 thanks 16:21:09 any other open biz? 16:21:24 (i'm just going to assume everyone agrees with my thoughts about the bof XD) 16:21:52 Who's going to formally reply to the description request? 16:21:52 #topic guidelines 16:22:04 edleafe: i suppose i can 16:22:29 #action elmiko respond to description request for forum bof 16:22:43 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:22:49 #link https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z 16:23:11 anything new here? 16:23:22 looks like no 16:23:39 nope 16:23:55 #topic bug review 16:24:02 #link https://bugs.launchpad.net/openstack-api-wg/+bugs?orderby=-id&start=0 16:24:08 #link https://bugs.launchpad.net/openstack-api-sig/+bugs?orderby=-id&start=0 16:24:14 i'm guessing same story here 16:24:37 heh 16:24:46 all quiet on the API-SIG front 16:24:53 some day we'll burn these old issues down ;) 16:24:57 haha ++ 16:24:59 #topic weekly newsletter 16:25:07 #link https://etherpad.openstack.org/p/api-sig-newsletter 16:25:17 volunteers? 16:25:43 * edleafe raises hand sheepishly 16:25:53 cool, thanks 16:26:10 Usual ping in -sdks when it is ready 16:26:13 any other last words for the meeting? 16:26:23 snark is always a good word 16:26:27 ++ 16:26:33 #endmeeting