16:00:10 #startmeeting api wg 16:00:15 Meeting started Thu Mar 23 16:00:10 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:19 The meeting name has been set to 'api_wg' 16:00:22 \o 16:00:27 #chair cdent elmiko edleafe 16:00:28 Current chairs: cdent edleafe elmiko 16:00:55 Any elmiko today? Anyone else along for the api-wg? 16:01:23 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:01:31 #topic previous meeting action items 16:01:32 o/ 16:01:42 #link http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-03-16-16.00.html 16:02:01 only action item was on edleafe to adopt the pagination guideline and he did it! 16:02:06 success 16:02:13 woo hoo! 16:02:40 it was also agreed that I should go back to bed, which I did, and though my cold still lingers, I'm much less poorly 16:02:45 o/ 16:02:58 \o/ 16:03:03 #topic open mic and new biz 16:03:18 * clarify api-wg is tc governed not uc governed 16:03:27 uc? 16:03:33 there's been some confusion on whether we are "governed" by the tc or the uc (user committee) 16:03:38 o/ 16:03:40 ahh 16:03:48 confusion where? 16:04:05 ML 16:04:06 the reason for some of the confusion is that the UC has us on some wiki pages and regularly contacts us about setting up time at summits and such 16:04:20 and in some presentations to the board the api-wg was "claimed" by the UC 16:04:29 so this inspired some asking around about what the truth was 16:04:59 and the truth is that api-wg is under the guidance of the tc and we need to make sure we're on the right wiki pages etc and off the wrong ones 16:05:01 interesting 16:05:07 You can't handle the truth!! 16:05:11 LOL 16:05:18 the basic dealio is is whether we meet at the ptg or ops meetups 16:05:23 you need me on this firewall! 16:05:39 since it is the ptg for us, that makes us tc 16:05:43 ptg seems more appropriate though 16:05:54 sorry, i'll stop interrupting now 16:05:55 i haven't yet located the who and what we need to clean up 16:06:07 ptg++ 16:06:09 so if people know or find stuff, feel free to take it upon yourself to tidy 16:06:15 ack 16:07:17 and presumably when emails start going round about UC stuff to the api-wg cores, we should let them know what's up 16:07:48 I've got a couple other new biz things that I only thought of today so are not on agenda, but before I monopolize, anyone else got something? stevelle? 16:08:06 I'm just here for the bagels 16:08:15 bagels!?!? 16:08:36 I was promised bagels and cream cheese 16:08:36 edleafe: did you eat all the bagels before giving me one? 16:08:56 Nope. I refuse to eat bagels that aren't from the NYC area 16:09:01 ooh, now i'm hungry... thanks stevelle ! 16:09:04 * edleafe is a bagel and pizza snob 16:09:12 * cdent is not shocked 16:09:12 edleafe hahaha 16:09:15 * stevelle is a helper 16:09:32 okay, then I'll take back the floor: 16:10:13 in conversation today about "what the api-wg does" there was an assertion that we produce guidelines, as in that's our job 16:10:43 I demurred suggesting that was a byproduct of our job, which is to work towards creating consistency and correctness in openstack apis 16:10:51 thoughts? 16:11:29 Those two do not seem orthogonal 16:11:33 indeed 16:11:49 IOW, the way to create consistency and correctness is via the guidelines 16:11:54 cdent: besides the docs how else is that done? 16:12:00 the way or a way? 16:12:11 i guess the question is how much "creating consistency and correctness" do we do beyond producing guidelines? 16:12:17 dstanek: by talking a lot and scrupulously encouraging input from lots of voices 16:12:37 what I just said to dstanek is the crux of the biscuit 16:12:37 ...so that we can create better guidelines! 16:12:42 good point cdent, we also help to facilitate the conversation 16:12:52 cdent: sure, but the product is the docs - that's what most people will see 16:13:31 imo, i think it's good not to gloss over the social factors that we bring to bare 16:13:34 the hard part of software engineering isn't the code, but unfortunately many see us as just 'coders' 16:13:34 dstanek: _one_ product is the docs, the primary product is better APIs 16:13:36 yeah, the reason this came up and the reason I'm bringing it up here is because of some disagreement over the extent to which I've made efforts to keep the conversations on the stability guideline ongoing 16:14:00 dtroyer: no, that is the goal 16:14:06 i like the 'the way' language as it shows a stonger opinion 16:14:08 we don't produce any APIs 16:14:38 dtroyer: i'm not disagreeing...i'm just saying why people think it's just docs 16:14:39 not directly, but that is one of the things that people should see 16:14:58 the indirection between the better apis makes it difficult to do more than infer correlation 16:15:22 between the better apis and the concrete products of the WG... 16:15:51 so maybe it is better said in the form cdent used, producing those conversations that lead to better APIs? 16:15:55 We do arbitrate to some degree when there are disagreements 16:15:59 stevelle: ++ 16:16:18 But we don't produce APIs 16:16:46 i see this group as 'architects' in a more traditional architecture role 16:16:52 dtroyer: +1 16:17:06 huh, apparently it is a good thing I brought this up, as it has revealed yet more (mild) disconnects. That's good. 16:17:06 stevelle: precisely. Our existence will help reduce the number of "this is my preference" decisions that can go different ways depending on the developer 16:18:23 I'm not sure there is a particular action we can take from this, other than to consider it as a question for a while "What is that we do?" 16:18:36 eat bagels? 16:18:40 ++ 16:18:41 i mention the agi-wg quite a bit when we are designing features (like tages and other apis) - sometimes i get asked when it is 16:19:05 it would be nice to have a clear, cohesive statement if one doesn't exist 16:19:13 mission statement of whatever 16:19:13 there is a mission statement 16:19:18 * jroll walks in late 16:19:24 http://specs.openstack.org/openstack/api-wg/ 16:19:53 but I'm not sure if it gets what we've actually done over the past couple of years 16:20:07 maybe time for a refresh? 16:20:41 I dunno. That's definitely _not_ what I was thinking of when I raised the topic. But if other people think so. 16:21:07 elmiko: thanks for volunteering! :) 16:21:15 XD 16:21:20 that sounds after the fact. i usually say that this group looks and what we have, best practices and helps us architect better apis 16:22:05 here's another angle 16:22:28 in the past we have made serious effort to document what is happening in the openstack world through our "current design" wiki 16:22:34 that is definitely another thing we produce 16:23:10 granted, it's more r&d, but still 16:23:57 So it seems there more to think about then I originally assumed. Should we articulate an agenda item for next week to think about in the interim (so that we can move on now)? 16:24:46 could we hold till the week after? (i'm out for kubecon next week) 16:24:50 sure 16:25:01 thanks 16:25:01 as long as you pay the forfeit of creating the agenda item 16:25:10 definitely 16:25:32 #action elmiko to make an agenda item to think about what we do 16:25:39 haha, beat me to it 16:26:44 next thing is the concrete incident of "keeping the conversation open". We need to bring the stability guideline to a close and the alternatives section is causing some stress. I've put some options in my last comment. we should figure it out and get on with things[1] 16:26:55 #link https://review.openstack.org/#/c/421846/ 16:27:21 [1] which is not to say we'll be done, we haven't even made it to freeze on this thing yet, so there may be yet more rounds of debate 16:27:49 LOL i *love* option 4 16:27:56 but, i think i'd vote for option 2 16:28:01 I was about to add to the review, but if this is a guideline that will be used as the basis for a particular TC tag, we should only have one recommendation 16:28:16 ooh, good point edleafe 16:28:47 i could definitely get on board with that line of thinking 16:28:56 isn't the alternative to every api-wg spec, to ignore the spec? which is a valid option, as the api wg isn't a mandate but a recommendation? 16:29:00 edleafe: ++ 16:29:02 I don't think we'll ever get agreement from everyone 16:29:06 jroll: right 16:29:15 probably no need to tell folks that explicitly 16:29:34 So we need to record the overall consensus 16:29:58 I'd like to avoid the situation where the guideline doesn't have enough info in it to avoid the common questions of "why aren't you doing _____ instead" 16:30:19 cdent++ 16:30:31 that's fair 16:30:31 if we can rely on people reviewing the gerrit record then no problem 16:30:33 cdent: that's different than providing alternatives 16:30:43 but if we can't then we need something 16:30:52 edleafe: yes, thus one of the options being "rename the section" 16:31:03 we often treat the 'alternatives' section in ironic like that - "how else could this be done, and why aren't we doing that?" 16:31:23 if we leave it in, i agree we need to change the language 16:31:24 cdent: Or integrate those ideas into the rest of the document 16:31:39 that's a reasonable 5th option yes 16:31:55 IOW, we reccommend X. We considered Y, but because of Z we rejected it 16:32:46 jroll: but a spec and a guideline are two different beasts 16:32:53 edleafe: does it make sense for you to write a new patch fulfilling that option? 16:32:56 (the option 5) 16:33:23 edleafe: sure, just thought that data point might be useful 16:34:16 *crickets* 16:35:16 The main problem is that there are people who simply do not like microversions 16:35:31 Some of it is based on misunderstanding how they work 16:35:41 Some is based on fears of misapplication 16:35:59 some is technical ;) 16:36:10 ++ 16:36:18 some of it is fear of overhead and instability (of the implementation, not the api) 16:36:32 "Microversions are the worst system for API stability, except for all the others" 16:36:40 LOL 16:36:41 the walls have ears! 16:37:01 cdent: i was just thinking the same, mention "microversions" and the channel really perks up 16:37:02 in some sense microversions are not germane 16:37:32 I have been tumbling around the ideas of alternatives to microversions and all I have right now is the opportunity to talk about an API maturity model 16:37:46 elmiko: I thought if mentioning free bagels didn't attract a crowd, nothing would :) 16:37:47 similar to Graham's comments 16:37:56 edleafe++ haha 16:38:21 stevelle: I'd love to see that 16:38:45 the document goes out of its way to say "microversion are the available tool, but even they weren't, we've still got all these issues witt changes that impact stability" 16:38:50 because I'm having a hard time figuring out how Graham's approach would work in the actual OpenStack world 16:38:51 edleafe: great, we can hold that for thinking later 16:39:16 edleafe: well, designate did it pretty successfuly 16:40:00 my personal problem with microversions is not microversions themselves. it just look to me like a solution seeking for problems. hence my nitpicks on "why" and use cases. 16:40:54 let's roll back a bit 16:40:57 my problem with microversions is that I do not think 90% of users will use them as they are so complex 16:41:01 mugsie: I didn't follow designate's development history, so I'd have to read more on their problems and solutions 16:41:29 mugsie, no worries, we force them into using microversions (usually in a wrong way) by hiding features in old versions :/ 16:41:39 edleafe: are you willing to write up a modification of the document in the way described by your option 5? 16:41:47 mugsie: interesting. The main point of microversions is that 90% of people will never have to know anything about them :) 16:42:09 cdent: perhaps next week, as I'm on 50% PTO this week 16:42:12 apart from the pewople who write tooling, or apps that talk to apis, or libraries 16:42:21 edleafe, this never worked like that (mostly due to bad implementations, not bad idea) 16:42:49 does anyone object to the option 5 idea which is to talk about the alternative in the body of document, rather than its own section 16:43:11 * jroll doesn't 16:43:22 cdent: depends on how it is proposed - it if is "this other way is wrong", I do 16:43:27 In the Nova case, the 2.1 behavior is exactly the same. No new tooling or clients have needed to change to get a stable response 16:44:00 cdent: no objection here 16:44:35 mugsie: would you be willing to propose your alternative? 16:44:53 IOW, have two proposals that people can compare? 16:44:54 #action edleafe to explore the apocryphal option 5 on the stability guideline 16:45:05 edleafe: yes, but not for a few days 16:45:35 mugsie: that's cool, since it doesn't seem like this thing is going to be solved in the immediate future 16:46:04 edleafe: ++ 16:46:17 cdent: I'd prefer to wait until I can read mugsie's proposal to write up a new version 16:46:37 cdent: it seems like there is a lack of clear understanding on both sides as to what the other is talking about 16:46:51 that's okay with me, but there's some (minor) time pressure because of the tag stuff, but I don't think it matters that much 16:47:12 cdent, I think it's important to define a tag that people will want to get 16:47:16 from my standpoint I just need to pass this particular ball to good hands 16:47:29 dtantsur: good point 16:47:31 as it's written now, I don't quite care about this tag for ironic, even though we probably comply with the guideline 16:47:54 k, let's move on? 16:48:00 # topic guidelines 16:48:04 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:48:29 jroll made a new one, which has had some interesting debate that probably needs to be resolved 16:48:39 #link add next_min_version https://review.openstack.org/#/c/446138/ 16:48:45 cdent, your #topic did not work btw 16:48:54 dtantsur: thanks whoos 16:48:58 #topic guidelines 16:49:15 yeah, there's just oen wedge in mine 16:49:31 and I think maybe perhaps pagination might be close? 16:49:37 #link pagination https://review.openstack.org/#/c/446716/ 16:50:01 and max length is a bit confused 16:50:12 #link max length tags: https://review.openstack.org/#/c/447344/ 16:50:22 The pagination started to descend into wanting implementation details 16:50:51 yeah, that whole pagination ordering thing seems out of scope for the api guideline 16:50:59 but maybe i'm just being myopic on this one 16:51:12 elmiko: yeah 16:51:14 we should but more of our eyes on that, and it should be ready to freeze for next week (it has no current reviews) 16:51:17 that just smells like a per-project issue depending on how they handle resources 16:51:21 s/but/put/ 16:51:38 more like per query/resource 16:51:41 the point that Qiming made about 404, _may_ be valid. not sure 16:51:57 the 404 thing is weird 16:52:04 404 is always weird with collection resources 16:52:24 yeah 16:52:47 this is like the issue we had awhile ago about returning 404 if a referenced resource in the body json is not there 16:52:55 I thought of 410 instead 16:53:10 Gone 16:53:12 * elmiko looks up 410 16:53:26 ahh, yeah 16:53:35 410 is for signifying very permanent goneness 16:53:43 and could apply to the url without parameters 16:53:44 BUt yeah, applying a single resource construct to a collection is weird 16:53:46 that's the issue here 16:54:24 A 'next' request is saying "give me some more resources, starting with this one" 16:54:49 s/with/after/ ? 16:54:54 When "this one" is gone, how do we react? 16:55:20 (5 minutes) 16:55:43 cdent: well, yea 16:55:47 yeah 16:55:55 same idea, thoguh 16:55:58 jeez 16:55:58 I still feel like it's 404, dunno... 16:55:59 though 16:56:19 It's definitely an edge of an edge case 16:56:26 edleafe: you've been spending too much time with my typing 16:56:45 * edleafe starts filtering cdent from his IRC client 16:57:01 #topic bugs 16:57:04 #link https://bugs.launchpad.net/openstack-api-wg/+bugs?orderby=-id&start=0 16:57:18 there's one new one, which is about tag lengths, mentioned above 16:57:31 so it is in progress, but some indecision on need to have it or not 16:57:52 #topic weekly newsletter 16:57:58 #link https://etherpad.openstack.org/p/api-wg-newsletter 16:58:18 I guess I'll do it this week and ping people in for a proof 16:58:22 any last words? 16:58:26 muchas gracias 16:58:38 "Either these curtains go..." 16:58:44 LOL 16:58:44 thanks cdent 16:59:04 despite our assertions last week that we were a bit quiet lately, seems there are actually many things to talk about 16:59:07 I guess that's good 16:59:15 yeah, totally! 16:59:17 :) 16:59:27 good attendence today, thanks all =) 16:59:37 thanks everyone for coming and helping make it interesting 16:59:39 thanks! 17:00:01 #endmeeting