16:01:39 #startmeeting api-wg 16:01:39 Meeting started Thu Sep 8 16:01:39 2016 UTC and is due to finish in 60 minutes. The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:43 The meeting name has been set to 'api_wg' 16:01:44 etoews: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 16:01:59 lol. 16:02:02 oops, i flubbed the start meeting 16:02:18 should i undo then restart? 16:02:22 #undo 16:02:35 nope. i flubbed it. no need to restart i think. 16:02:53 i was just popping up to say i can't make it :) 16:02:54 hi 16:02:57 ok, didn't i mess up the name though? 16:03:01 haha 16:03:03 hi scottda 16:03:05 elmiko: you did it right 16:03:08 I'm only half here 16:03:17 k 16:03:25 #chair cdent elmiko etoews 16:03:26 Current chairs: cdent elmiko etoews 16:03:34 hi 16:03:34 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda\ 16:03:38 #undo 16:03:39 Removing item from minutes: 16:03:41 #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda 16:04:25 i think this is gonna get screwed up in the log archives. i named the meeting "api-wg" should be "api wg" 16:04:45 ah well, maybe meetbot did the right thing 16:04:53 elmiko: i think it translates 16:04:58 yeah, looks like it 16:05:12 i don't think we had any action items from last time 16:05:41 #topic Consistent endpoint discover 16:05:49 #link http://markmail.org/message/o4k7wd7vqxon2ypk 16:06:14 not sure who added this topic, does anyone have a comment on it? 16:07:18 that was me, I thought the email was relevant to us, but couldn't decide, wanted to highlight it 16:07:26 cool 16:07:36 * elmiko still reading it 16:09:14 interesting topic, i'm not exactly clear on the course of action. dont' microversion already get us to a point of determinism for the resources? 16:10:15 the concern there is that there's no clean way to get the microversion info 16:10:22 for many situation you get / 16:10:27 but sometimes that is authed 16:10:30 sometimes it is not there 16:10:44 oh, gotcha 16:11:06 i thought we had talked about standardizing a version response endpoint 16:12:00 yeah, we started this: 16:12:02 https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Entry_Points 16:12:03 #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses 16:12:03 ? 16:12:33 those 2 pages could probably be related 16:13:08 true.. 16:13:26 what could be the rationale behind not requiring authentication though? 16:13:28 I'll update that cinder/block storage part...we've v3 endpoint now with microversions. 16:14:14 gouthamr: i think mainly so you could discover things like version level, which may or may not be seen as needing auth 16:15:53 elmiko: yes, but i'm thinking in terms of applications that might initialize client/s with that information.. and that would be used to make other requests.. so, the auth information should be there? 16:16:14 yeah, that makes sense 16:16:32 i'm not sure about the intent behind having this info not require auth 16:17:01 elmiko: i think it is more about consistency than any particular preference 16:17:09 ah, gotcha 16:17:45 so, i guess my question is, do we want to take the version response research and attempt to craft a guideline based on it? 16:17:56 * elmiko double checks to make sure we didn't do that already 16:18:33 yeah, i don't see anything yet 16:18:48 https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery 16:19:15 ah, nice. good one gouthamr 16:19:24 i thought we did something about this lol 16:20:53 elmiko: yes, the guideline already suggests that the versions endpoint "should return the minimum and maximum versions".. we should probably address the concern regarding authentication there 16:21:03 unfortunately, it seems like we need to get consistency about the version negotiations 16:21:19 yeah, what is the guidance though? 16:22:00 i mean, i don't see a reason to have the root version endpoint be authenticated, but that's just my opinion 16:22:39 hmmm, not sure on this one.. nova, cinder, manila require authentication 16:22:50 I don't think cinder does... 16:23:05 oh.. might be wrong.. 16:23:31 maybe we should start by doing an analysis of the services now 16:23:35 no, cinder does not need auth 16:23:45 look through them all and see who wants auth for that endpoint 16:24:13 if a majority require auth, no reason to advice against that 16:24:18 What about keystone? How do we figure out which version (when they have microversions) if we need auth to check? 16:24:27 good point 16:25:45 i guess that's partially why i'm in favor of no auth for version discovery. but, this is an effort someone would need to champion across the projects, just as Krotscheck suggests in the email 16:26:32 scottda elmiko: okay, i was wrong.. manila doesn't need auth too 16:26:58 gouthamr: That makes sense. Since I copied Cinder's from Manila :) 16:27:54 scottda: :) and we copied from nova.. so.. lemme quickly confirm nova's status 16:28:40 okay, not sure how the OP tested this.. but http://paste.openstack.org/show/569259/ 16:29:37 not sure, maybe worth engaging on the ml 16:29:44 It's quite likely things have changed 16:29:45 elmiko: +1 16:30:10 In any case we don't need to solve this today, the agenda item was: do we own this. Sounds like we do :) 16:30:53 gouthamr: would you be willing to make a response on the ml? 16:31:21 elmiko: sure thing 16:31:25 thanks! 16:31:52 #action gouthamr respond to Michael Krotscheck's email about consistent endpoint discovery 16:32:06 #topic Prepping any summit stuff 16:32:23 who else aside from cdent is going to barcelona? 16:33:04 scottda and I will be there.. 16:33:06 I'm not sure yet, but probably I will go. 16:33:09 very cool! 16:33:14 oh :P you have a talk scottda 16:33:15 https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15434/api-microversions-for-operators-what-why-and-how 16:33:27 cdent: are you going to lead a wg session? 16:33:42 gouthamr: I'm pretty sure, but things change within my company, so I'm being cautious... 16:33:48 scottda: :) 16:34:27 elmiko: I had hoped to ask about that today and get suggestions on what it should do, if it is just me and the limited space available ,etc 16:34:36 k 16:34:36 but myattention is very partial right now 16:34:43 maybe we keep this on the agenda till next week then 16:35:04 if we do a session, we'll need the usual etherpad with topics, etc 16:35:21 although, next thursday is the deadline... 16:35:47 cdent: etoews: maybe we should shoot for a BoF gathering instead of a full session if it's going to be light? 16:35:58 we can do some email, especially since next thursday I'll be at pyconuk 16:36:04 k 16:36:08 we'll table for now then 16:36:11 yeah bof seems nice 16:36:27 might be more appropriate, although we did have a good crowd in austin 16:36:36 #topic guidelines 16:36:43 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:36:51 only one open right now, not a guideline per se 16:37:09 i like you suggestions cdent, i need to make another version but could use a little more advice 16:39:06 #topic bug review 16:39:12 #link https://bugs.launchpad.net/openstack-api-wg 16:39:16 yeah, I just saw that, will think about it 16:39:25 cool, thanks cdent ! 16:39:27 no new bugs, and no recent changes except for your thing 16:39:45 we still have several open bugs, just wanted to post in case folks are looking for something to do =) 16:40:00 i'm not taking a new one till i finish that one ;P 16:40:41 #topic APIImpact 16:40:46 i have doing the one about summary of testing types on my to do list but it keeps getting deferred 16:40:52 #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z 16:40:57 cdent: i hear that... 16:41:13 any APIImpact reviews that people would like to highlight? 16:43:50 #topic open mic 16:43:55 any other business? 16:44:11 i can handle the weekly newsletter 16:44:25 reality presents many challenges in the face of doing cross project stuff :( 16:44:31 this is an upsetting problem 16:44:33 so true... 16:49:49 cdent: do you have a link to notmyname's comments about the payload stuff? 16:50:09 * cdent thinks 16:50:42 i'm trying to remember where that was 16:50:50 it was like a review or something 16:50:58 https://review.openstack.org/#/c/322194/ 16:51:02 not a lot there, but some 16:51:06 thanks! 16:51:12 and some here https://review.openstack.org/#/c/354266/ 16:51:14 both very short 16:52:06 payload? 16:52:18 * notmyname tries to catch up 16:52:21 what's going on? 16:52:39 we are trying to address some comments you had about the implicit assumptions in the api-wg guidelines about json bodies and whatnot 16:53:04 we'd like to be more clear about what we are generally referring to when speaking about APIs and their payload contents 16:53:06 ah, ok. cool 16:53:15 i think we all agree you made some very salient points 16:53:32 thanks 16:54:19 and thank you for the input =) 16:54:50 is there something further I can help with? 16:55:05 i don't think so, i just wanted to have some links to provide reference for our newsletter 16:56:33 #topic weekly newsletter 16:56:40 #link https://etherpad.openstack.org/p/api-wg-newsletter 16:56:47 cdent: that look good to you ^^ 16:57:01 * cdent reads 16:57:50 quick skim reads well 16:57:56 cool, thanks 16:58:43 if there is no other business, i'm gonna end the meeting 16:58:49 thanks everyone for showing up! 16:59:01 #endmeeting