16:00:16 #startmeeting api-wg 16:00:17 Meeting started Thu Nov 3 16:00:16 2016 UTC and is due to finish in 60 minutes. The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:20 The meeting name has been set to 'api_wg' 16:00:34 o/ 16:00:52 hello o/ 16:01:06 hmmm 16:01:22 hi 16:01:24 i missed the meeting in the summit due to a conflict :/ 16:01:28 not seeing the usual meetbot notices 16:01:56 #chair etoews elmiko 16:01:57 Current chairs: cdent elmiko etoews 16:02:10 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:02:10 meetbot is slow today ;) 16:02:37 fyi, i'm gonna miss the next 3 meeting. i'm at 2xconferences then vacation 16:02:49 no meeting last week, no action items from the meeting the week prior 16:03:05 * cdent wags finger at elmiko 16:03:13 lol 16:03:22 #topic open mic 16:03:45 summit report: we had a bof and it was good 16:03:47 #link: https://etherpad.openstack.org/p/api-wg-ocata-bof 16:04:21 not a lot of active input but was good to see interested people. There were somewhere between 10 and 15 people there. Probably would have been more but we were in a hard to find spot (again) 16:04:37 nice turnout, bummer about the space issue 16:05:02 Many of the attendees were there out of curiosity, not with any active desire to write guidelines. More of a "what does this group do" kind of thing. So I, with a good bit of help from edleafe, told them. 16:05:47 sweet 16:05:53 The main point I made was pointing out how nearly all the words in the api-wg mission statement are subject to (mis)interpretation 16:05:59 i'm curious about the pushback you mentioned from the arch-wg 16:06:19 ya. that seems strange to me too 16:06:35 you mean the people responding negtaively to the arch-wg? 16:07:49 it's the same thing as ever: People not wanting to be told what to do and thinking that such groups want to do that. the api-wg had similar reactions early on 16:08:05 the cross-project-goals stuff that is in flight had a similar reaction 16:08:38 lots of trust issues 16:09:44 the other thing to draw attention to from summit are the raw results from the api feedback gathering that piet did, I made an html version: 16:09:48 #link https://burningchrome.com/api-feedback.html 16:10:17 huh, oh well, guess we need more messaging! 16:10:37 or the arch-wg needs more messaging? 16:10:48 I think people are happy with the api-wg these days, they just haven't learned the lesson we've set: we're there to help, advise, provide guidance, not enforce 16:10:56 but people haven't got that message on arch-wg 16:11:01 hehe, i guess i meant us, but i can see how that could be interpretted either way ;) 16:11:47 i thought our messaging was really clear though, maybe it was just an awareness issue with the arch-wg 16:11:53 cdent: did things turn out ok in the ned? 16:11:58 s/ned/end/ 16:12:24 well for the api-wg side of things, yes: We were held up as an example of how to do things and a paragon of success and value 16:12:47 to which I said something like "great, please come help us do more" 16:13:02 haha, nice! 16:13:11 but for the arch-wg things are still up in the air, let me find a link 16:13:55 #link http://fewbar.com/2016/10/openstack-architecture-wg-because-we-all-arent-gaudi/ 16:14:25 cool, thanks! 16:14:47 on the api-feedback thing above, two of the most visible things to me were: 16:14:56 people want more info in error messages 16:15:03 people are curious about the porcelain idea 16:15:29 what is the porcelain idea? 16:16:04 instead of ameliorating the bad UI of the existing http APIs at the client level (a la openstackclient) do it with an overarching API 16:16:25 ah, cool 16:16:34 which would effectively mean you could say "get me a thing" instead of: get me a network port, get me some disk, get me a vm 16:16:51 still lipstick on a pig but at a lower layer 16:17:02 interesting 16:17:13 every problem can be solved by adding another layer of indirection 16:17:17 also, this arch-wg blog post sounds very ambitious. good luck to them! 16:17:31 the idea here is that the layer is at a place where anyone can benefit, not just people using a particular client 16:17:40 +1 layer of indirection 16:17:40 right 16:17:51 would there then be a porcelain client(s)? 16:18:01 out of curiosity, where did that idea come from? 16:18:21 I put the question on the api feedback etherpad, just to go fishing 16:18:42 but the idea of having such an api has been bounced around by lots of different people, independently 16:19:18 I suspect its earliest incarnation was when bits started being spun off from nova 16:19:37 and the proxy apis in there started to exist, and then people realized that was icky 16:20:11 but also that the UX of using multiple apis was icky too 16:21:02 at the beginning of the year jaypipes, alaski, tdurakov and I worked on version of the concept: 16:21:23 #link https://github.com/jaypipes/enamel 16:21:31 but like most things it got lost to the real world 16:21:56 as I understand things, lots people, including harlowja, have made various attempts at different times 16:22:14 seems like a good windmill to tilt at 16:23:24 shall we attempt to resolve the question "should we put API porcelain in our domain?" so it can finally be removed from the agenda? 16:23:27 It's not something I would think anything could happen with in the immediate future, just something to keep in mind 16:23:36 that was almost a jinx 16:24:01 but yeah, I think we can probably take that off the agenda 16:24:15 if it gets some legs we could consider it then 16:24:15 as long as the concept stays in our brains 16:24:19 * cdent nods 16:24:20 seems like it would _not_ be in our domain, unless we had some sort of project team 16:24:45 i would expect api-wg members to be involved, but leading the effort, not so sure 16:25:07 not the building of, sure 16:25:15 that's what i meant 16:25:43 agreed 16:25:52 cool. anybody got more to say on the feedback doc or anything else, or shall we move on? 16:26:32 #topic guidelines 16:26:37 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:26:49 new stuff! 16:27:11 thanks for the updates cdent ! 16:27:32 ++ 16:27:47 when https://review.openstack.org/#/c/386614/ was frozen did it the cpls get invited in? 16:28:01 i did not invite them, my bad 16:28:29 ah, okay, I was kind of assuming that that one would stir some negative responses 16:28:34 it did get mentioned in the newsletter, but that was right before summit 16:30:15 the pagination guideline is going to need more active work, with an eye to its predecessors: https://review.openstack.org/#/c/390973/ 16:31:39 looks like it 16:31:59 elmiko: looks CPL pestering was missed on https://review.openstack.org/#/c/383862/ too 16:32:47 yeah, i totally flubbed it on the cpl pestering 16:33:23 elmiko: are you running it now or should i? 16:33:25 do we have a script for adding those folks? 16:33:54 383862 has a new push, so feel free 16:34:09 i can remove my +2 on the other one as well if you want to take over? 16:35:34 elmiko: it's api-wg/tools/add-reviewers.py 16:35:50 ack, thanks! 16:36:10 elmiko: you said you're missing the next few weeks right? 16:36:14 yes 16:36:31 i'll take over those frozen ones and begin pestering 16:36:37 thanks =) 16:38:35 * cdent has started filling in the newsletter 16:38:56 Are we ready to move on to the next topic? 16:39:31 +1 16:39:52 #topic bug review 16:39:59 etoews made a new bug and yeah, who knows: 16:40:06 #link: https://bugs.launchpad.net/openstack-api-wg/+bug/1636641 16:40:06 Launchpad bug 1636641 in openstack-api-wg "What are the valid microversion statuses?" [Undecided,New] 16:40:40 that seems like a worthy bug 16:40:45 ¯\_(ツ)_/¯ 16:40:49 lol 16:43:14 cdent: i'm going ahead and freezing https://review.openstack.org/#/c/392156/ 16:45:49 i froze https://review.openstack.org/386614 https://review.openstack.org/392156 https://review.openstack.org/383862 16:45:58 thanks etoews 16:48:19 lame 16:48:20 internet took a dive 16:48:25 =( 16:49:08 etoews: are you considering https://review.openstack.org/#/c/392156/ effectively a typo 16:49:29 and thus okay with early freeze? 16:49:42 yep. that was my thought process. 16:49:53 get out of my brain cdent! 16:50:05 * cdent IS EVERYWHERE 16:50:06 lol 16:51:27 back to CURRENT momentarily: where should we go for the answer to that? 16:51:54 erm...what? 16:52:27 not sure on that one, i guess look at the most advanced microvers. stuff and see what they implemented? 16:53:14 etoews: clearly i'm not in your mind etoews, otherwise I would have communicated that more clearly 16:53:26 oh. we're back on microversion statuses. 16:54:09 maybe there's a hint on http://developer.openstack.org/api-guide/quick-start/index.html 16:54:21 Current API versions 16:54:22 Supported API versions 16:54:22 Deprecated API versions 16:54:40 nice 16:54:53 i love an easy answer 16:55:29 i commented on the bug 16:55:42 seems reasonable. another interesting thing from the api-feedback thing was that many people don't think about microversions much 16:55:57 of course the group was probably biased in some fashion, they were self selected 16:56:41 i have to say that sahara is going to drop plans for implementing microversions in the v2 api 16:56:52 it's just too much overhead for not enough value 16:56:56 \o/ 16:57:19 if you change your mind, the way I've implemented it in the placement api is pretty simple 16:57:24 so that might be a good reference 16:57:45 ack, i'll bring it up with them, but i think in the case of that project it just doesn't make sense 16:58:09 oh don't let me encourage you. I think they are to be avoided where possible 16:59:09 oh dear, we've run out of time 16:59:22 * etoews looks at watch he doesn't have 16:59:30 any last minutes before we move it to #openstack-sdks ? 16:59:42 (i'll do the newsletter) 17:00:03 thanks cdent ! 17:00:14 #endmeeting