16:00:09 <cdent> #startmeeting api-wg
16:00:10 <openstack> Meeting started Thu Feb  2 16:00:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'api_wg'
16:00:26 <cdent> #chair edleafe etoews
16:00:27 <openstack> Current chairs: cdent edleafe etoews
16:00:34 <etoews> o/
16:00:41 <rosmaita> o/
16:00:50 <edleafe> \o
16:01:07 <scottda> hi
16:01:11 <lamt> o/
16:01:13 <cdent> hi everybody
16:01:45 <cdent> #topic old biz and actions
16:01:47 <cdent> #link http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-26-16.00.html
16:02:09 <cdent> I was supposed to schmooze with the arch-wg about spending time at the ptg
16:02:10 <cdent> I did
16:02:11 <cdent> they were happy
16:02:17 <cdent> we started some discussions about topics. some for daytime
16:02:20 <cdent> some for bar
16:02:33 <rosmaita> foo bar?
16:02:40 <etoews> :)
16:02:52 <cdent> #link etherpad for arch-wg ptg talk: https://etherpad.openstack.org/p/ptg-architecture-workgroup
16:03:36 <scottda> I know we can't schedule cross-project talks, but is there an etherpad or some way to register names of interested individuals?
16:03:51 <scottda> This came up for the Consistent Endpoints conversation...
16:04:39 <scottda> I guess just that etherpad ^^^ :)
16:04:39 <cdent> scottda: yeah, lots of people have expressed this problem
16:04:45 <cdent> and that etherpad is one way
16:04:51 <cdent> but I think we're going to have etherpad conflicts
16:05:10 <cdent> as, for example, the py35-goals etherpad has the same thing: people registering their interest
16:05:14 <cdent> but not in a global way
16:05:28 <cdent> on the day of there is going to be an ethercalc to help people manage space and topics
16:05:32 <scottda> Maybe we need a meta-etherpad, that points to all the other etherpads...
16:05:35 <cdent> but I hope we start that before the day of
16:05:48 <scottda> cdent: OK.
16:06:14 <cdent> #action cdent to agitate with whomever to make sure the ethercalc is available before ptg
16:07:16 <edleafe> scottda: like https://wiki.openstack.org/wiki/PTG/Pike/Etherpads ?
16:07:37 <scottda> edleafe: Yeah, like that.
16:07:56 <cdent> #link ptg link of etherpads https://wiki.openstack.org/wiki/PTG/Pike/Etherpads
16:08:26 <cdent> The other action item was that edleafe and cdent were going to hobnob over how freezing etc works. We didn't do that because of cycle timing
16:09:07 <cdent> so we'll keep that for next time
16:09:16 <cdent> #action edleafe to get with cdent to talk about freezing
16:09:31 <cdent> #topic open mic and new biz
16:09:35 <edleafe> cool
16:09:54 <cdent> "We probably need to cleanup and correct the list of people notified when we freeze"
16:10:25 <cdent> I realized that when we pester people with the auto-pester script we're probably not up to date. I'm not sure I remember where that list comes from or what it even means. etoews ?
16:11:15 <etoews> it's all documented here http://specs.openstack.org/openstack/api-wg/liaisons.html
16:11:32 <etoews> (which is linked to from step #2 of http://specs.openstack.org/openstack/api-wg/process.html )
16:12:34 <cdent> yes, but do we have any indication that the json file is being kept up to date?
16:12:56 <etoews> that's up to the liaison's themselves
16:13:00 <cdent> hmmm, perhaps so, the last change was november last year, which is relatively good
16:13:35 <cdent> I think we should add something in today's newletter reminding projects that that's the case
16:13:58 <edleafe> cdent: yes, especially with PTL elections ongoing
16:14:09 <edleafe> new PTLs should be reminded of this
16:14:43 <etoews> see also #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
16:15:21 <cdent> k, moving on
16:15:55 <cdent> let's reorder and talk "Glance!" before stability guidelines as they are related and "Glance!" will warm us up. rosmaita, you ready ?
16:16:01 <rosmaita> sure
16:16:11 <rosmaita> Really need some timely input on this
16:16:21 <rosmaita> Here's the context: there's a disagreement between the Glance team and the QA team on what's the correct way to fix a bug.
16:16:30 <rosmaita> (links in agenda)
16:16:38 <rosmaita> I think this is a clear case where the docs are correct, so the code should change, but some on the QA team think the docs have to change (which ordinarily would be the correct move, but I don't think so in this case)
16:16:50 <rosmaita> Anyway, Glance requests some timely advice. because while we were holding our patch until we received some advice, a tempest test was merged
16:16:59 <rosmaita> This test will have to be reverted if the Glance patch is accepted, which of course is going to slow things down during RC time
16:17:10 <rosmaita> which is really annoying because the QA team knew full well this issue was under discussion and that I was holding the Glance patch until we'd talked it over
16:17:19 <rosmaita> so i just want to state out loud my opinion that this power play by the QA team was not made in the proper community spirit
16:17:28 <rosmaita> but i digress
16:17:43 <cdent> QA is being an activist judiciary?
16:17:51 <rosmaita> at least
16:18:12 <rosmaita> self-appointed, to boot
16:18:18 <rosmaita> but again, i digress
16:18:32 <rosmaita> my ask is if you could look those over and let me know what you think
16:18:40 <edleafe> My problem in understanding this is I don't use Glance on a regular enough basis to be affected by this, so I'm taking people's word for it
16:18:56 <edleafe> Some say that this change makes sense, and operators will be hurt without it
16:19:10 <rosmaita> this is a different change, i think
16:19:11 <edleafe> The QA people say that making this change will cause all sorts of operator pain
16:19:15 <rosmaita> the visibility one got through
16:19:32 <rosmaita> this change is just that a DELETE call for a metadefs operation returns 200
16:19:33 <edleafe> rosmaita: ah, I hadn't seen that
16:19:39 <rosmaita> it is documented to return 204
16:19:45 <edleafe> the last time I saw it QA was pretty strident about it
16:19:50 <rosmaita> and all the other DELETEs for metadefs do in fact return 204
16:20:02 <rosmaita> they seem to be strident about everything
16:20:07 <edleafe> heh
16:20:09 <rosmaita> (oops did i say that out loud)
16:20:28 <cdent> Long ago and far away the goal of the api-wg was to achieve consistency across and within the apis
16:20:52 <cdent> a random delete operation that behaves differently from all the others "next" to it is inconsistent
16:21:01 <rosmaita> that is my thought, too
16:21:17 <rosmaita> but, if the openstack consensus is inconsistent but stable is the ideal, we will do that
16:21:33 <rosmaita> i'm just trying to figure out if i'm being stubborn or reasonable
16:21:50 <rosmaita> so my ask is to give me some feedback about that
16:21:54 <edleafe> And if it's documented to return 204, then it's a bug if it returns 200
16:22:18 <rosmaita> that's what i think, the docs do provide a contract
16:22:24 <cdent> success handling is often fairly generic, such that 200 and 204 are both in the class of "success". So the stability cost here is different from changing a 403 to a 400 (or whatever)
16:22:53 <rosmaita> yeah, i think a consumer who hard coded in a 200 expectation here would be ... inept
16:23:07 <rosmaita> the other thing is, if we change the docs, we need to make a big deal about it
16:23:13 <rosmaita> becuase otherwise it looks like a typo
16:23:19 <rosmaita> given what all the other operations do
16:23:23 * cdent nods
16:23:24 <rosmaita> which is fine
16:23:34 <rosmaita> if that's the appropriate thing to do
16:24:27 <rosmaita> well, that's basically it ... would appreciate whether the fast fix (just change the docs) or the slow fix (get the code change + tempest test change) is the way to go
16:24:46 <etoews> it seems to this is clearly a code bug. so the bug should be fixed. period.
16:24:46 <etoews> if not, openstack risks going down the path of internet explorer where people wind up coding to the bugs and that way lies madness.
16:24:56 <cdent> I think, unfortunately, you're going to need to go to the TC with this. The underlying issue is with regard to qa activism (which is a reasonable role for them to take, to a degree). You've got a sympathetic ear, but little in the way of executive power
16:24:58 <edleafe> Agree
16:25:01 <rosmaita> the IE care!
16:25:03 <rosmaita> *card
16:25:08 <rosmaita> wish i'd thought of that
16:25:12 <rosmaita> :)
16:25:35 <edleafe> BTW, my "agree" was with etoews' assessment
16:25:40 <cdent> we three can pile on the review, if that will help
16:25:53 <cdent> but I don't think that will change anything in any permanent sense
16:25:59 <rosmaita> yes, it would be good to see soem consensus
16:26:02 <rosmaita> *some
16:26:11 <rosmaita> i will take it to the TC
16:26:31 <rosmaita> just wanted to make sure i had done appropriate groudwork first
16:26:49 <cdent> I think so. edleafe, etoews ?
16:27:05 <edleafe> Yes, I think an #agreed is in order
16:27:23 <etoews> sure
16:28:21 <edleafe> #agreed The bug in https://bugs.launchpad.net/glance/+bug/1656183 is a code bug, not a documentation bug. The code should be fixed to return 204.
16:28:21 <openstack> Launchpad bug 1656183 in Glance "Delete tags return 200 status code but api-ref says 204" [High,In progress] - Assigned to Ian Cordasco (icordasc)
16:28:29 <edleafe> Is that ok?
16:28:35 <cdent> i reckon so
16:28:46 * sigmavirus did not expect that resolution
16:29:14 <rosmaita> sigmavirus: call me roosmaita
16:29:28 <edleafe> sigmavirus: what resolution was your money on?
16:29:48 <asettle> sigmavirus rosmaita - do you two just meet all day in separate channels?
16:29:50 <sigmavirus> edleafe: that it was a doc bug
16:29:55 <sigmavirus> asettle: yes
16:30:02 <asettle> Cool. I take my leave.
16:30:05 <rosmaita> asettle: we have to stop meeting like this
16:30:11 <sigmavirus> rosmaita: or do we?
16:30:24 <asettle> *twilight zone music*
16:30:37 <cdent> sigmavirus: the api-wg is evidently not in the camp of permanent stability
16:30:41 <asettle> I'm running a meeting in the other room if you guys wanna pop in :p
16:31:13 <rosmaita> i think the api-wg stives for "flexible stability"
16:31:25 <edleafe> sigmavirus: If every similar delete method returns a 204, consistency would say that that method is incorrect
16:31:27 <rosmaita> not handicapping rigidity
16:32:08 <cdent> sigmavirus: which is part of why I keep asking for input on the stabilty guideline, because it's hard to write about something like that without help from both the true believers and the opposers and the compromisers
16:32:09 <cdent> which is a nice segue to the next topic
16:32:54 <cdent> which can be summarized as: I'm really struggling to have any mental traction on refactoring/correcting etc the stability guidelines
16:32:59 <edleafe> masterful sequeway
16:33:10 <rosmaita> cdent: i have a really unhelpful comment
16:33:24 <rosmaita> the more i think about it, the more this stability tag seems like a bad idea
16:33:43 <rosmaita> because, does it mean that if glance, for instance, doesn't adopt it
16:33:49 <rosmaita> we can do whatever the heck we want?
16:33:57 <rosmaita> that woudl be insane
16:34:21 <rosmaita> i think we really need to all strive for stability period
16:34:37 <rosmaita> also, is tag application retroactive?
16:34:48 <rosmaita> like, the visibility thing we just went through
16:34:54 <rosmaita> are we doomed from ever getting the tag?
16:35:00 <rosmaita> if so, wild west time!
16:35:08 <edleafe> rosmaita: the tag is the TC's way of saying that "this project has achieved the stability as defined by x, y, and z..."
16:35:22 <cdent> and it is at a point in time
16:35:30 <cdent> from release X, this project's api is stable
16:35:45 <cdent> s/api is/is asserting its api is/
16:35:54 <edleafe> rosmaita: Not having the tag just means that a consumer cannot rely on that project to have as stable an API as OpenStack would like
16:35:54 <rosmaita> though that's not much help to people who want to use release Y
16:36:21 <rosmaita> ok, thanks, maybe i've been thinking about this the wrong way
16:36:42 <edleafe> projects don't adopt that tag
16:37:05 <edleafe> It's assigned to them, based on the guidelines under discussion
16:37:12 <cdent> edleafe: that's not entirely true
16:37:27 <edleafe> cdent: oh? Enlighten me
16:37:29 <cdent> the assertion tags (which this one is) are chosen by a project
16:37:46 <cdent> and they are responsible for making that assertion
16:38:01 <cdent> the TC has to validate the gerrit change
16:38:04 <cdent> but the projects make it
16:38:30 <edleafe> I understood that to be more procedural
16:38:48 <edleafe> Instead of the TC constantly combing the projects and evaluating each one
16:39:11 <edleafe> when a project feels that it's ready, it creates the tag change
16:39:19 <edleafe> which is the signal to the TC
16:39:50 <cdent> https://review.openstack.org/#/c/418010/3/reference/tags/assert_supports-api-compatibility.rst
16:40:08 <cdent> an assertion tag is described as "self-imposed contract"
16:40:47 <edleafe> So a project can propose the tag change as much as they want, but it is the TC that always approves it
16:41:09 <rosmaita> so, tbh, the reason i've been stubborn about that bug mentioned earlier, is that i'm trying to figure out what kind of "compatibility" we're talking about -- consistency across APIs or IE-style sitck-with-what-you've-got
16:41:10 <cdent> I think it is more that a project can choose _not_ to propose the tag
16:41:32 <edleafe> cdent: well, yeah, that's the flip side of the definition
16:42:08 <cdent> edleafe: and given rosmaita's concerns I'd be hard pressed to understand why any project (which didn't have microversions) would ever want to
16:42:44 <cdent> rosmaita: from my perception of the people responding on the guidelines it is "ie-style stick-with-what-you've-got for ever and ever amen"
16:42:50 <cdent> except that
16:43:09 <cdent> for those project that have microversions there is an immediately accessible get out of jail free card
16:43:17 <cdent> except that card is only useful to developers of the project
16:43:23 <rosmaita> hopefully this is not off topic, but what are the deprecation rules for microversions?
16:43:32 <cdent> not really all that useful to users of the api
16:43:40 <cdent> rosmaita: again depends on who you talk to
16:43:44 <edleafe> rosmaita: my take is that you cannot change an API, except if not changing it causes more pain that doing so
16:43:45 <cdent> some people say never
16:43:55 <edleafe> rosmaita: that's a very high bar to cross
16:45:09 <scottda> edleafe: My take is you can change an api (to a new microversion) but not remove the old one.
16:45:15 <edleafe> rosmaita: technically, a project could document that after a cycle, the minumum supported microversion will be a number higher than the current minimum
16:45:40 <rosmaita> edleafe: that makes sense, it would give people some time to adjust
16:45:43 <edleafe> rosmaita: but, at least among Nova, we've said that that will probably never happen
16:45:57 <scottda> Most in Cinder say it will never happen
16:45:58 <cdent> edleafe: that would violate the stability guidelines, if they are being followed to the letter of some people's laws
16:46:28 <cdent> there is a vocal body of people who think none of the http apis should be deprecated ever
16:46:44 <cdent> there is a much less vocal body that thinks this allows tech debt to live forever
16:46:45 <edleafe> cdent: sure, but nova has already indicated that it will break stability by dropping the code to support nova-network
16:47:38 <scottda> I'd like to see a conversation about changing our understanding of microversions to allow incrementing the major version for a breaking change.
16:47:52 <edleafe> No one wants to support that rotting bit of tech debt
16:48:02 <cdent> We've got 13 minutes before we finish up. I feel like we're going round (and have been going round) in circles on this topic and I'm not sure what to do about it.
16:48:19 <scottda> Maybe we can mark things as "unsupported" and stay away from "deprecated"
16:48:20 <edleafe> scottda: there is no concept of "major version" with microversions
16:48:21 <etoews> rosmaita with respect to deprecation, it's https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html if you assert that tag
16:48:21 <etoews> if you don't assert that tag then ¯\_(ツ)_/¯
16:48:26 <scottda> edleafe: I know.
16:49:14 <scottda> edleafe: But to me, that is a cause of great confusion. We should just have microversions be interpreted as "versions" with the ability to bump both major and minor number
16:49:19 <edleafe> scottda: ah, ok. Some people think that since Nova's start at 2.1 and go up to 2.42 (now), at some point, we will go to 3.0
16:49:42 <scottda> edleafe: Yes. IF nova removes nova networking (for example), go to 3.0
16:49:58 <scottda> sure makes it easier to know when the change is, as opposed to "in microversion 2.87"
16:50:17 <scottda> and makes it easier to explain to all the confused developers I work with...
16:50:23 <cdent> :)
16:50:23 <scottda> who hate microversions.
16:50:36 <edleafe> scottda: so no one will be able to request 2.21 anymore? Because that version won't have nova-network anymore, either
16:50:57 <scottda> sure, you can request whatever "version" of the api you want...
16:51:06 <scottda> using the existing mechanism in the HTTP header
16:51:29 <scottda> It's just a more user-friendly way of incrementing the numbers. Basically, semver
16:51:48 <edleafe> scottda: So at some point 2.x supports nova-net. Then nova-net is dropped. Now that same version number will behave differently
16:52:09 <scottda> edleafe: why would 2.x behave differently?
16:52:23 <scottda> it's no different than microversions today
16:52:38 <etoews> at this point i think you're really just discussing deprecation
16:52:43 <edleafe> scottda: Because if you call a nova-net function as request version 2.x, it will no longer work
16:52:46 <scottda> if nova-net is dropped in 2.87,  you can use nova-net if you request 2.85
16:53:03 <edleafe> scottda: no
16:53:09 <edleafe> the code is gone
16:53:10 <edleafe> deleted
16:53:13 <scottda> edleafe: Well, I'm assuming the code stays in the code base.
16:53:21 <cdent> completely violating the microversion concept btw :)
16:53:24 <edleafe> scottda: that's the difference - it's gone
16:53:25 <cdent> 7 minutes
16:53:25 <scottda> edleafe: If the code is deleted, then all bets are off
16:53:36 <scottda> OK, we can talk more at the PTG
16:53:37 <edleafe> scottda: my point exactly
16:53:49 <edleafe> Let's move on
16:54:18 <cdent> Yes, let's. Can people apply some of this enthusiams to the associated email threads and reviews (see link in the agenda).
16:54:34 <cdent> #topic guidlines
16:54:38 <cdent> I thikn we can merge some stuff
16:54:48 <cdent> #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:55:05 <cdent> the stuff frozen last week didn't get any objects
16:55:08 <cdent> objections
16:55:26 <edleafe> Not exactly controversial stuff :)
16:55:32 <cdent> true
16:55:40 <cdent> i'll merge (since I froze)
16:55:58 <edleafe> Haven't gotten any more input on the boolean patch
16:56:53 <edleafe> If people could go there just to register your preference for style, that would be a big help
16:57:12 <edleafe> I.e.: 'is_enabled' or 'enabled' for naming
16:57:27 <cdent> #action everyone look at https://review.openstack.org/#/c/411529/ to express preference on booleans
16:57:48 <etoews> i'm fine with it as written (hence my +1)
16:57:49 <cdent> capabilities is on the agenda (from several etherpads) for the ptg
16:58:35 <cdent> i'm not sure on the status of pagination: https://review.openstack.org/#/c/390973/
16:59:20 <cdent> any last words (I'll get the newsletter)
16:59:32 <edleafe> I'm good
17:00:00 <cdent> thanks everyone for coming and trying to get to the bottom of things
17:00:09 <cdent> #endmeeting