16:00:13 #startmeeting api_wg 16:00:14 Meeting started Thu Mar 30 16:00:13 2017 UTC and is due to finish in 60 minutes. The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:18 The meeting name has been set to 'api_wg' 16:00:22 #chair cdent elmiko edleafe 16:00:23 Warning: Nick not in channel: cdent 16:00:24 Current chairs: cdent edleafe elmiko 16:00:30 Who's here? 16:01:14 * edleafe is feeling lonely... 16:03:06 Well, I'll go through the motions, at least :) 16:03:07 #link Agenda https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:03:16 #topic previous meeting action items 16:03:17 #link http://eavesdrop.openstack.org/meetings/api_wg/2017/ 16:03:25 First: 16:03:25 elmiko to make an agenda item to think about what we do 16:03:27 (referring to the mission statement part of http://specs.openstack.org/openstack/api-wg/process.html) 16:03:57 Since no elmiko here, I'll defer to next week 16:04:01 #action elmiko to make an agenda item to think about what we do 16:04:16 Also: 16:04:16 edleafe to explore the apocryphal option 5 on the stability guideline 16:04:19 that is, https://review.openstack.org/#/c/421846/ 16:04:43 I'm not clear exactly where we are, but I have tried to spur discussion in the review. 16:04:54 #topic open mic and new biz 16:05:15 Don't really fancy hearing myself talk (or type) so... 16:05:17 #topic guidelines 16:05:24 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:05:31 I think that this is ready for freeze: 16:05:32 #link pagination guideline https://review.openstack.org/446716 16:05:46 This is trivial, but I wanted at least one more OK before merging: 16:05:47 # link clarify meaning of BODY https://review.openstack.org/451568 16:06:03 #topic bug review 16:06:09 nothing exciting here 16:06:11 #topic weekly newsletter 16:06:20 #link https://etherpad.openstack.org/p/api-wg-newsletter 16:06:27 Guess I'll take that one :) 16:07:01 So I'm done. I'll keep the meeting open for a bit in case there are stragglers who arrive late. 16:07:54 I just watched because not much to say 16:08:15 guessing we don't have bagels this week since it wasn't your turn to bring them 16:08:22 * edleafe is relieved that he isn't the only one appearing in the logs :) 16:08:47 I can offer you some lukewarm coffee 16:08:58 I got a cup of that already 16:09:04 heh 16:09:31 so on the stability guideline. I lost track of what option 5 really means 16:09:46 me too 16:10:08 IIRC, it was the option of assuming "robust" clients who could handle addtions 16:10:09 phew. 16:10:23 Like new URLs and extra properties in a response 16:10:44 IOW, the anti-Monty proposal 16:10:57 It might also be the non-microversion one, too 16:11:09 like going with a more semver-like approach 16:11:19 so do we need someone to take that assumption and roll through the proposal shouting 'bin it' everywhere to reduce the scope? 16:11:45 yeah, I dunno 16:11:47 that way we can rehash every argument? 16:11:59 this is the sort of thing that is best done in person, like at the PTG 16:12:08 agreed 16:12:16 The only problem is we had one side in the morning, and the response in the afternoon 16:12:24 No back-and-forth between the two 16:12:46 The latest version is based on those discussions. 16:12:55 without a time schedule it was really tough to predice. collectively we'll learn 16:13:03 So it seems odd to go back to before they happened 16:13:25 This seems like something that would be hard to iterate on 16:13:40 We have to get pretty freakin' close on the first shot 16:13:57 so extra properties or not, the functionality of a robust client would seem to be the LCD of a feature set 16:14:20 trying to exceed the LCD requires something like a 'smart' client instead of 'robust' 16:14:30 so I think we have a natural ceiling to how much that helps 16:15:13 and that's not compatible with the Monty scenario of strict cross-cloud compatibility 16:15:22 also true 16:15:23 hey, wait 16:15:25 mordred 16:15:27 mordred 16:15:28 OA 16:15:35 ugh 16:15:38 mordred 16:15:56 maybe if I say his nick 3 times he'll magically appear 16:16:51 have to stand in front of a mirror with the lights off? 16:17:16 i do have my garlic necklace on 16:17:49 Well, I hope that we can discuss this in person again, although neither cdent nor I will be at the Forum in Boston 16:18:00 same same 16:18:35 Maybe we need two tags: API stability, and cloud interop compatibility 16:18:53 The former is the "robust client" standard, and the latter is the Monty standard 16:18:58 I think that is a solid idea 16:19:05 much more versatile 16:19:23 The only problem is that most projects will never bother with the latter 16:19:29 too difficult 16:19:40 for too little (or no) benefit to themselves 16:19:56 Hmmm, maybe I should write a blog post on this 16:20:23 though interop implies stability so we have a kind of tiered tag which was rejected in one form at PTG. this is different however in that this idea cuts functionally rather than on a measure of adherence. 16:20:28 that makes it like the upgrade tags 16:20:57 nova will get the interop tag at least, right? 16:21:01 exactly, it's not like "stable" and "pretty stable" 16:21:21 anyway, +1 for exploring stability and interop tags separate 16:21:34 Well, nova, ironic, placement, and any other microversion-based project 16:22:00 though as has been discussed, ironic has a bit of a challenge in their extensions 16:23:07 I think that if cloud A runs ironic with the same extensions as cloud B, the responses at the same version should be the same, no? 16:24:15 what if they have different extensions? I'm not an expert on this 16:25:11 I felt like I remembered that there was message format differences w/ different extensions. That may have been worked out in terms of scope of the tag at ptg? 16:25:28 well, that sound like we're drifting back into the absolutist realm 16:25:42 nova has adopted an absolutist postion: no extensions, period 16:25:49 that won't work with other projects 16:26:19 fair enough, and I think there are projects who then can do interop now. 16:26:24 My understanding is that two clouds runnign the same extensions would return the same format 16:26:25 just not many 16:26:42 different extension, though, would probably differ 16:26:58 and that's ok 16:27:02 agreed. 16:27:59 and if someone wants to propose an image service API that can claim interop, that seems like a win. 16:28:19 well, thanks for showing up. I think I'll crank out the newsletter and then write up a blog post on this 16:28:22 same for other services that might be on the fringe, heat et al 16:28:40 yup, looking forward to reading it. 16:30:33 #endmeeting