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