16:01:04 #startmeeting api-sig 16:01:04 Meeting started Thu Jan 4 16:01:04 2018 UTC and is due to finish in 60 minutes. The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:07 The meeting name has been set to 'api_sig' 16:01:15 o/ 16:01:18 #chair cdent elmiko edleafe dtantsur 16:01:19 #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda 16:01:19 Warning: Nick not in channel: cdent 16:01:21 Warning: Nick not in channel: dtantsur 16:01:23 Current chairs: cdent dtantsur edleafe elmiko 16:01:50 let's wait for cdent 16:02:02 sorry, lost track of time in tc office hours... 16:02:04 dtantsur said he wouldn't be able to make it 16:02:37 #topic previous meeting action items 16:02:38 #link http://eavesdrop.openstack.org/meetings/api_sig/2017/ 16:02:46 There were none, so... 16:02:52 #topic open mic and ongoing or new biz 16:03:14 Are any of the topics on the agenda in need of discussion? 16:03:23 Or are they just leftover from the last meeting? 16:03:42 i didn't add anything 16:04:57 cdent: anything to discuss about the foundation summary report? 16:05:24 I added a few things to the agenda, to try and use it as a way of keeping track of stuff that is sort of in progress 16:05:46 the main new thing was the foundation summary thing, which is just that they want someone to write up a bit of a summary of 2017 in api-wg/sig 16:05:49 which I'll do 16:05:56 #action cdent write up foundation summary thing 16:06:03 thanks cdent 16:06:18 the plan is to mention a few highlights (interop, service discovery, becoming a sig, sdk exploration) and leave it at that 16:06:24 * edleafe breathes a sigh of relief 16:07:06 sounds good to me, maybe mention adding a new core too? 16:07:54 sure, makes sense 16:09:00 OK, so anything else for new/ongoing biz? 16:09:28 not entirely related, but did people see my post on gabbi tempest to os-dev today? 16:09:34 it's kinda cool 16:09:57 i did not, but will now =) 16:10:18 not yet - still getting settled after wasting 2 hours commuting 16:10:36 sorry for your luck 16:11:11 +1 16:13:11 I added info about generating machine readible output to os-api-ref to https://review.openstack.org/524467 16:13:38 and a patch to os-api-ref to do it - https://review.openstack.org/#/c/528801/ 16:13:56 mugsie++ 16:14:22 what's your general level of happiness with that? is it "a nice try" or "omg I love this" or "let's never look here again"? 16:14:52 the patch to os-api-ref is hacky as hell, but if people are interested I can clean it up - I think "a nice try" 16:14:58 while i definitely am on the mugsie++ bandwagon, i like this effort, i thought we backed away from advising openapi(ex. swagger) for the api definitions, did that change? 16:15:15 we're still backed awayfrom that 16:15:27 this is something nearby but not the same 16:15:33 elmiko: its not OpenAPI - it looks like http://paste.openstack.org/show/629241/ 16:15:46 microversions are also not accounted for yet 16:16:11 such a bugbear 16:16:15 ahh, ok. thanks! that's what i get for skimming the pr... 16:16:38 Kinda looks like SOAP++ 16:17:05 yeah, I'm very conflicted about this stuff 16:17:07 yeah - it looks a bit like what gilles had done before 16:17:21 I can see how/why people want it 16:17:27 but I don't think it will result in excellent apis 16:18:21 I'm not sure how (or if I even need) to resolve that conflict 16:18:31 What is the use case that is driving this interest? 16:18:42 auto generating client libs 16:19:32 gilles is already using the docs to do so, but thinks more structured will be better 16:20:14 i agree that a structured format is the way to go, will someone need to develop tools for the generation stuff given that this is not openapi? 16:20:40 or is gilles handling that 16:21:00 he has a ruby lib that does it already, but not for this exact format 16:21:06 but only for ruby 16:21:27 ack, thanks 16:21:30 that's part of the issue I have: if we're going to have a structured format, we should do something standard if possible (says the guy who made gabbi's own special format...) 16:21:43 i tend to agree 16:21:57 (on both accounts XD) 16:22:09 then we should just add it to gabbi 16:22:10 I would agree, but afaik microversions have a issue being modeled by OpenAPI ? 16:22:13 * edleafe runs 16:22:36 edleafe: ++ /s 16:22:38 mugsie: yeah, that is the main issue as i see it for openapi in the openstack ecosystem 16:23:35 openapi is great for designing a new API, and modeling a lot, but it has a few built in (common sense IMHO) constraints 16:23:45 * mugsie now ducks 16:23:58 (as an aside, I have a todo list for gabbi<->openapi transpiler like thing, but stalled on time) 16:24:21 mugsie: you're quite right about that too 16:26:16 yeah, agreed mugsie 16:26:33 ready to move on? 16:26:34 is there a next step? 16:26:41 so that the ball doesn't get dropped? 16:27:04 not sure - gilles seems happy with it, but I am not sure a lot of people actually care either way? 16:27:32 a persistent problem 16:27:42 i tend to agree, this api schema stuff is far enough into the weeds that few decide to venture this way 16:27:54 but, it could have a big impact if we could figure it out 16:28:17 let we = someone in the community at large 16:28:21 yeah - there is a ML thread gilles started - let me resurect that and see what happens 16:28:27 +1 16:28:58 sounds good 16:29:43 let's move on 16:29:44 #topic guidelines 16:29:44 #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z 16:29:47 #link https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z 16:29:53 Nothing new here 16:30:21 Anyone want to talk about guidelines? 16:30:27 not today 16:30:52 #topic bug review 16:30:53 #link https://bugs.launchpad.net/openstack-api-wg 16:30:58 No new bugs 16:31:25 C'mon people, you need to start creating more bugs!!! 16:31:32 no progress on bugs either, but it's been a complex time 16:31:44 edleafe: can i make a bug about more bugs? 16:31:59 * edleafe cues the Inception reference 16:32:02 haha 16:32:05 I had some talks with mordred today and yesterday about issues with pagination inconsistency and how we need to start pushing harder those sorts of things being bugs 16:32:15 maybe we can create joint bugs with various projects that violate 16:32:25 cdent: do you mean bugs on the projects that implement? 16:33:05 yeah 16:33:25 cdent: do the offending projects' API pre-date the guidelines? 16:33:45 frequently yes, and that's the point. We need to start driving some change. 16:34:27 i have mixed feelings about this 16:34:31 it seems that we need to start breaking APIs to fix them 16:34:41 mainly due to the historical idea that we are not the api police 16:35:22 cdent: what could be the carrot we could use instead of the API police stick? 16:35:23 we don't have to cross link the bugs to us, but in general I think openstack is doing itself a disservice of not treating inconsistencies as bugs 16:35:33 cdent: ++ 16:35:44 cdent: i think that's an entirely fair position 16:35:47 so we may not be the police, but somebody needs to be the complainant 16:36:20 i can get behind an effort to work with the projects, open bugs, and raise these issues as long as it's not the api police 16:37:05 the point about opening bugs and not necessarily cross-linking back to the sig is very sane 16:37:51 i'm a little troubled by the idea that we might cause major version bumps for projects that need to restructure their pagination api though 16:38:06 but maybe that's just developer angst on my part 16:38:24 elmiko: we shouldn't be - we should support decent version discovery, and itterate as needed 16:38:33 you can support the old and the new in the same output 16:38:46 s/can/can also/ 16:39:18 but we needn't fall in a hole here, the real goal is to make things better, how we do that remains to be discovered, that we don't know should not stop us hoping 16:40:00 agreed mugsie and cdent, i'm just being paranoid most liekly 16:40:17 we should promote the forward movement and improvement of these projects 16:40:17 * cdent didn't think elmiko livedin california 16:40:35 * elmiko chuckles 16:41:14 then again I am the one deleting designate'sV1 API, so I am on the opposite side of the arguement 16:41:22 hahaha 16:42:30 mugsie: https://blog.leafe.com/api-longevity/ 16:44:15 edleafe: yeah - it has taken us a while :) - we have had it turned off by default for a year now 16:44:24 good analogy in there edleafe +1 16:44:36 yeah - I like it 16:46:11 So what action will we take to handle this "encouragement" of projects to update their pagination links? 16:46:49 not sure, was just throwing it out there as an anecdote 16:47:23 OK, I'll add it to the agenda so we can discuss next week - maybe someone will have some ideas 16:47:33 #topic weekly newsletter 16:47:34 #link https://etherpad.openstack.org/p/api-sig-newsletter 16:47:39 Volunteers? 16:47:50 i have a meeting immediately after this one today 16:47:56 i can take it 16:48:02 thanks elmiko 16:48:16 cool, thanks 16:48:23 I can review when it's ready 16:48:28 cool, thanks 16:48:41 With that, let's get back to whatever we were doing before 16:48:42 cool, cool 16:48:45 #endmeeting