16:00:01 #startmeeting api-wg 16:00:01 Meeting started Thu Apr 27 16:00:01 2017 UTC and is due to finish in 60 minutes. The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 The meeting name has been set to 'api_wg' 16:00:13 hi 16:00:15 \o 16:00:20 #chair edleafe elmiko 16:00:21 Current chairs: cdent edleafe elmiko 16:00:33 anyone else joining us today? 16:01:05 ah, there we go 16:01:08 * mordred waves at the nice people 16:01:23 * edleafe is sad that mordred didn't wave at him, too 16:01:25 #topoic previous meeting actions 16:01:27 LOL 16:01:34 oops 16:01:40 #topic previous meeting actions 16:01:45 you misspelled 'tapioca' 16:01:54 elmiko and I are supposed to be preparing for the forum 16:01:59 * cdent looks at elmiko sheepishly 16:02:11 * elmiko is preparing furiously 16:02:17 well done 16:02:31 edleafe was to ping liaisons 16:02:45 there was email, anything after that edleafe ? 16:02:59 I got a few responses, but not much 16:03:13 Heat will have to find a new liaison 16:03:35 Manilla too 16:03:45 the usual rule for cross project liaisons is that it is the PTL in the absence of them designating someone else 16:04:16 so one option would be to set missing people or projects to the ptl? 16:04:37 I also asked for email addresses so that we can reach them outside of Gerrit reviews 16:05:26 We could set to PTL, but we don't know how many of the liaisons are no longer able to do the role, or how many didn't respond 16:05:36 * edleafe thinks that's sort of the same thing :) 16:05:51 i just meant set to ptl for the missing projects and the people we know are missing 16:05:54 i like adding the ptls then making ridiculous demands 16:05:56 and leave the rest to rust 16:06:26 Sure, but that does nothing to address our concern about "silence is consent" 16:06:33 yes 16:06:48 but it may be better than the current situation 16:07:35 * cdent doesn't have any ideas 16:07:52 maybe silence is just gonna mean approval and that's the way it goes 16:07:55 it seemed like we were using our best idea 16:09:13 elmiko I guess you and I can farm people at the BOF for ideas, but usual the attendees are not PTLs and CPLs 16:09:20 right 16:09:28 so besides that, that leaves wait and see. edleafe ? 16:09:46 I like silence is assent until it becomes a problem 16:09:56 given the nature of the openstack community, i'm not sure there is anything more substantial we can do 16:09:57 I mean, I don't "like" it - but I don't see a better choice atm 16:09:57 I'm out of ideas. If there isn't that much interest... 16:10:06 mordred: you like that because you've written a lot of things that you want people to assent to ;) 16:10:11 cdent: yup 16:10:32 edleafe: right, we can't "force" pppl to participate 16:10:37 * edleafe posts a review that obligates CPLs to pay me $100 16:10:40 cdent: but seriously, we easily get hamstrung in openstack waiting for active consensus from people who have decided to not respond 16:10:44 and that's not great either 16:10:45 edleafe: +1 16:10:49 mordred: true 16:10:55 it's just...a bummer 16:11:05 cdent: too true 16:11:07 we've made an effort, so I guess we move on 16:11:09 eventually something will happen that will piss someone off and they'll start paying attention 16:11:10 mordred: that's "as good as it's gonna get" :) 16:11:13 edleafe: ++ 16:11:26 alright, move on to next topic? 16:11:46 i like the idea that we are as transparent as possible, give folks ample time to raise issues, and then make the guidelines published 16:12:15 if it becomes an issue, then yeah, folks will complain and, ideally,they will get more involved 16:12:25 yup 16:12:37 yah - and making a best-effort to ping any peope we can happen to know are specifically impacted when reasonable 16:12:38 not like we are hiding 16:12:49 the agenda is a bit out of date, we've just covered what's listed as the one new biz 16:12:51 mordred: absolutely 16:12:52 #topic new biz 16:13:10 but edleafe pointed out a good point in his last comment on: https://review.openstack.org/#/c/421846/ 16:13:24 i accidently implicitly approved a not yet approved guideline 16:14:18 hmm 16:14:36 seems like we need to get the dependent one merged to then 16:14:45 or leave out that bit 16:14:53 man, i never imagined we'd need a dep graph for guidelines lol 16:14:54 or not care and assume the other wil merge 16:15:04 Since jroll is not in a position to continue on the signaling patch, I can pick it up 16:15:20 edleafe: I had the same thing, but if you want it, have at 16:15:26 s/had/had said/ 16:15:36 edleafe: thanks for that 16:15:41 We can hold off on the stability guideline until that is merged. If it is killed, then we can update the stability patch 16:15:47 cdent: I think maybe just leaving that bit out, then putting in a patch that depends on the next_min_version patch that updates the api_interop doc with the next_min_version stuff? 16:15:47 I still consider it done, just need to get people to agree 16:16:05 jroll: zactly 16:16:20 that's why I figure let's not muck with the stability patch 16:16:23 yeah, i kinda agree with mordred here. maybe best to leave out the dependent bit and then update when the other merges 16:16:25 edleafe: there's some desire to get the stability thing merged so the tc proposal that wants it can move 16:16:26 or maybe even add the next_min_version bits to jroll's patch so that it can be seen in the context of how it changes the api_interop doc? 16:16:30 just hold off merging for now 16:17:54 The one contentious part left is the time aspect 16:18:15 IOW, the guarantee that it won't change before $date 16:18:33 #link next_min_version: https://review.openstack.org/#/c/446138/ 16:18:55 But thinking about that now, that could take a while to resolve 16:19:17 * cdent nods 16:19:18 So maybe just drop the wording from stability, re-freeze, and merge it next week? 16:19:21 yeah, that seems like it will need some time in the oven 16:19:36 works for me 16:19:38 edleafe: ++ 16:19:39 i'm +1 for rewording 16:21:08 i've push a new version which s/,.*/\./ 16:21:17 i figured simple was best 16:21:56 elmiko, edleafe can one of you glance and refreeze if it is sufficient? 16:22:21 ack 16:22:24 I'd be somewhat inclined to think that was a small enough change to be a typo 16:22:33 and thus we can just merge it 16:22:38 but I'm probably violating protocol somehow 16:22:58 you, violate a protocol, i'm shocked i tell you, shocked! 16:23:14 * cdent has infectious PTSD from mordred 16:23:20 LOL 16:23:46 \o/ 16:23:49 Re-frozen 16:24:28 yeah, that change lgtm 16:24:32 * edleafe is super-conservative, as everyone who knows me will attest to 16:24:41 * cdent guffaws 16:24:45 * elmiko sarcasm meter goes off 16:25:09 Anyone else have any other new business? mordred did you want to chat about your novels? 16:25:15 omg, remember a few weeks ago we joked about sarcasm aaS? 16:25:21 soo.... 16:25:30 my group dug up all these machine learning articles about sarcasm detection 16:25:41 I mean, I have written several very large and mind-hurting new documents 16:25:47 uh oh 16:26:03 I will apologize in advance for the one on consuming discovery - it definitely hurts 16:26:05 #link discovery-related proposed guidelines: https://review.openstack.org/#/c/459405/ 16:26:20 yeah don't let that one put you off. the rest of them pay out 16:26:29 No exaggeration - it took me almost 3 hours to digest the first one 16:26:37 it might be worth a couple of seconds of background of how we even got here real quick ... 16:26:38 wow 16:27:01 elmiko: the later versions had better examples that made things a bit clearer 16:27:01 background++ 16:27:14 ahh, gotcha 16:27:15 mordred: go for it! 16:27:20 and yeah, background++ 16:27:21 over in shade-land we're currently working on swiching from client libs to direct REST - which has been quite pleasant overall 16:27:42 but we got to the point where we needed to do version discovery for the third time, and it seemed like we should maybe write a general function 16:27:55 that's when we learned that keystoneauth already has a general function to do version discovery 16:28:00 (yay!) 16:28:11 but it didn't quite do all the things we needed 16:28:15 next step - add them! 16:28:49 but ... ksa has some nice logic, and we wanted ot add some new cases - and it quickly became clear that there was not a general understanding of what the 'right' thing to do was 16:28:58 other than just waht the existing libs happened to have already been doing 16:29:28 so I have _no_idea_ how people in non-python land could hope to navigate that, if it's even hard for those of us with the libs 16:30:13 anywho - I wrote up what I have come to understand as the complete process that covers all of the edge cases and is forwards compatible with how we'd LIKE it to work in the future 16:30:25 that, then,led to writing down what we'd like it to be the in future ) 16:30:27 :) 16:30:54 does this tie in at all to the early proposals we had for adding api discoverability to the guidelines? 16:31:12 i think we have some json-home stuff in there 16:31:13 The biggest problem with reviewing is that (aside from grammar and the like) none of us have the domain knowledge that mordred does 16:32:37 I've been pulling catalogs and version discovery docs from various clouds and just walking through them by hand - which isn't super pleasant - but yah, we need to come up with a better way to vett the actual logic itself 16:33:10 #link http://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html 16:33:15 #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses 16:33:21 elmiko: the version discovery stuff doesn't change much realted to api-discoverability as much as just capture current state and what folks have been generally saying at summits and ptgs 16:33:53 mordred: ah, gotcha. i hesitate to ask, but does this approach the HATEOS kinda stuff? 16:34:05 elmiko: it's definitely based around the version document that's in the microversions document being the "right" way for those to look- but it should hande all of the versoin documents you just linked 16:34:29 ack 16:34:32 elmiko: not that I'm aware of 16:34:36 elmiko: your question reminds me of something that came up while I was reading mordred's stuff: we need, fairly regularly, to read the guidelines as a body of work and make sure we rationalize it for modern times and added docs and the like 16:34:55 cdent: +1 i like that intention 16:35:05 ++ 16:35:26 cdent: oh, so you're handing out homework now? :) 16:35:41 well, i'll need to read up on morded's proposals before i could comment (semi-)intelligently ;) 16:35:57 it seems like a great direction to go though 16:36:44 elmiko: the most contentious one is likely to be the third one in the stack, where I propose a completely new thing for clouds to deploy :) 16:36:52 LOL 16:37:03 because that *always* goes over well 16:37:09 the first two should be fairly uncontroversial pending validation of their correctness 16:37:21 ack, are the other 2 linked from the first? 16:37:26 yah 16:37:29 it's a stack 16:37:44 cool, i will read it before the forum 16:37:45 of 5! 16:37:58 oh - actually, api-wg owns service-types-authority too, right? 16:38:01 i'll have plenty of airplane time and conference time next week ;) 16:38:03 edleafe: yes, I'm handing out homework for all of us, because clearly none of us have enough to do 16:38:05 mordred: sort of 16:38:13 there's overlap 16:38:17 but not concurrency 16:38:23 cause this morning, based on a question from dtroyer, I added: https://review.openstack.org/#/c/460539/ 16:38:47 (which cdent asked some excellent questions on) 16:39:02 they can probably be translated as "what was dtroyer's question?" 16:39:30 "how do we describe to people what to do about volumev2" 16:39:41 huh, apparently i'm still core reviewer on service-types-authority 16:39:47 KILL IT WITH FIRE 16:39:52 lol 16:39:56 * cdent apologizes for his outburst 16:39:59 https://review.openstack.org/#/c/460654/ is the consuming-version-discovery-process impact of that change 16:40:09 cdent: yah. so much agreement 16:40:32 but it's again a thing that we have encoded in a few libraries, which makes it tribal-knowledge 16:40:52 and if we cna put it somewhere in something akin to official guidance of how to consume some of these resources 16:41:01 i'm curious, how come you're moving away from libs in favor of rest? 16:41:09 it might be reasonable to expect peopel outside of our bubble to havea chance of navigating it properly 16:41:16 elmiko: the libs provide negative value 16:41:23 ack 16:41:40 tshirt 16:41:44 LOL 16:41:50 elmiko: basically, they are thin verneers over REST, and hide some of the nicenes from the REST 16:42:00 cdent: i would so wear that 16:42:01 but they introduce a giant pile of dependency issues 16:42:13 right, that makes sense. i was just curious 16:42:14 so it's a huge amount of pain for no benefit 16:42:35 elmiko: it's a great question! I have learned from the process that the openstack rest apis are actually much better than I thought they were 16:42:50 mordred: that's very cool and encouraging 16:42:53 and the things I was frustrated with were actually their representation in our python libs 16:43:07 wow, that's really interesting 16:43:09 yah. it's _way_ clearer to consume the thing the devs actually expose :) 16:43:17 heh 16:43:23 * cdent has been saying that from the start... 16:43:40 although this does make me wistful that openapi doesn't fit the openstack world 16:44:01 ~15 minute warning 16:44:26 I think this week it is mordred that is passing out the homework, not me 16:44:35 too true 16:44:49 :) 16:44:51 cdent: you're just piling on :) 16:45:04 although, on the topic of re-reading the docs from time to time. it seems like a great activity to plan for the api-wg "bug week" 16:45:14 well - honestly, I REALLY appreciate people reading these- the responses so far have been super helpful and we've made several improvements in them already 16:45:49 I do apologize for how complex the first one it - but also, that's the current state of the wrld 16:45:54 so - yay! 16:46:09 no worries, i'll definitely take a gander 16:46:09 I think it's great stuff to have 16:46:29 mordred: they are a royal pain to read, so I wouldn't read them if they weren't also really important 16:46:46 so thanks for putting them together 16:46:56 Is there any additional business before we move on to managing the guidelines? 16:47:09 move ahead! 16:47:10 nothing from me 16:47:14 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:47:43 one frozen thing was defrosted and then refrozen, so that will make us ill, so don't eat it 16:47:52 hehe 16:47:59 the other two frozen things are good to merge, so I will, now 16:48:32 edleafe wins at stackalytics 16:48:53 cdent gets paid by LOC 16:48:55 nothing is ready to be frozen 16:49:05 I get paid? 16:49:10 ouch 16:49:31 monty's new stuff is grand, and will be announced in the newsletter 16:49:41 +1 16:49:41 jroll's thing will be taken over by edleafe 16:50:08 sdague's microversion architecture thing is a long term wip 16:50:31 capabilities needs a new owner, but also might make more sense to abandon because we kind of killed it at the PTG 16:50:38 #action edleafe to adopt jroll's patch 16:50:59 thoughts on what to do about capabilities? 16:51:00 cdent: +1 on abandoning capabilities 16:51:04 roger that 16:51:07 * cdent does it 16:52:46 anything else about guidelines? 16:53:08 (note that I've been sloppy about #links through here because the newsletter will cover all that) 16:53:29 yay sloppy! 16:53:36 #topic bug review 16:53:45 #link https://bugs.launchpad.net/openstack-api-wg 16:54:04 nothing new 16:54:22 but also no progress on the existing bug. we should probably have a bug squash like elmiko said above 16:55:01 #topic weekly newsletter 16:55:08 Most are TODOs, so we can probably each take one 16:55:20 #link https://etherpad.openstack.org/p/api-wg-newsletter 16:55:36 yes, it's really just a matter of doing them, not any real complexity 16:55:51 I guess i is proabably about my turn for the newsletter? 16:55:55 I have to run right after the meeting, so would you mind doing the newsletter, cdent? 16:56:01 jinxish 16:56:06 not-quite-jinx 16:56:12 jinx ** 2 16:56:18 * cdent explodes 16:56:35 elmiko: will you be around in a bit for proofing ping? 16:57:03 yes 16:57:14 cool, will do so 16:57:22 heads up, i'm out next week. i'll try to make the meeting, but i will be at a conference so... 16:57:30 thanks for coming mordred and thanks for huge contributions, you are this weeks golden cookie recipient 16:58:01 +1 16:58:06 thanks mordred ! 16:58:20 and with that 16:58:23 #endmeeting