16:00:09 <cdent> #startmeeting api-wg
16:00:10 <openstack> Meeting started Thu Jan 12 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:14 <openstack> The meeting name has been set to 'api_wg'
16:00:16 <elmiko> hehe beat me to it
16:00:18 <cdent> we will start no meeting before its time
16:00:23 <scottda> hi
16:00:27 <cdent> say hi if you're here for the meeting
16:00:34 <edleafe> \o
16:00:37 <cdent> scottda gets a gold star
16:00:38 <rosmaita> hi
16:00:39 <elmiko> hi if you're here for the meeting
16:00:48 <stevelle> hi
16:00:48 <scottda> yay!
16:00:50 <mordred> hi
16:00:51 <cdent> #link agenda https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:00:53 <sigmavirus> hey y'all
16:01:00 <cdent> elmiko gets a platinum star
16:01:01 <elmiko> nice, big crowd today =)
16:01:03 <elmiko> LOL
16:01:23 <cdent> #topic old biz
16:01:44 <cdent> #link last minutes http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-05-16.00.html
16:02:06 <cdent> the only action item was to review the glance change in tempest, for which there is a slot later in the agenda
16:02:26 <cdent> so
16:02:36 <cdent> #topic new biz: service types authority
16:02:47 <cdent> #link https://github.com/openstack/service-types-authority
16:02:58 <cdent> does anyone not know or need a refresher on what that is?
16:03:20 * mordred welcomes our new service types authority overlords
16:03:28 <elmiko> haha
16:03:56 <cdent> so I reckon that's in our wheelhouse. should it be in our bailiwick?
16:04:21 * edleafe needs a refreshed on that vocabulary
16:04:24 <cdent> it has its own core reviewers and everything, but it stalled out in the face of other things last year
16:04:28 <edleafe> refresher, even
16:04:29 <elmiko> i thought there was already a fair amount of crossover in the cores for api-wg and service-type
16:05:04 <cdent> wheelhouse: a style we like, bailiwick: things we care about, service types authority: a repo that authorizes the service types to go in the service catalog to avoid collision and lead to cohesion
16:05:34 <elmiko> hmm, given that definition. i'm +1 wheelhouse, -1 bailiwick
16:06:04 <cdent> we don't really need to own it in any official capacity but I think it would be useful for us to a) track it and be good about reviewing, b) make refrence to it in guidelines
16:06:18 <elmiko> that's entirely reasonable
16:06:20 <cdent> (especially the latter)
16:06:43 <cdent> because if the service catalog is no good, we've got bad foundations
16:06:44 <edleafe> What part of that would be needed in API guidelines?
16:07:25 <edleafe> s/needed in/covered by
16:07:27 <cdent> I was thinking something along the lines of a) use the service catalog b) use the names from the service types authority in your catalog c) refer to things in the catalog by type not name
16:08:02 <mordred> don't append a version string to your service type
16:08:04 <cdent> I suspect mordred can provide some additional thoughts on that?
16:08:09 <cdent> jinx-ish
16:08:23 <mordred> cdent: yah - I agree with those things
16:08:56 <cdent> anybody disagree?
16:09:18 <cdent> rosmaita: you here? how do you feel about not use a version string in service type?
16:09:33 <rosmaita> here, thinking
16:10:47 <rosmaita> you mean a version string in the actual type name, for example
16:10:55 <rosmaita> "image-v2"
16:10:57 <mordred> I'm picking on volumev2
16:10:58 <rosmaita> instead of "image"
16:11:07 <rosmaita> yeah, i don't like it
16:11:08 <scottda> yeah, and now we have volumev3
16:11:15 <scottda> which is my doing, full disclosure
16:11:20 <scottda> I hate that, though.
16:11:41 <rosmaita> i like the model where you get the type object, and it has some endpoints in it that have version inof
16:11:44 <rosmaita> *info
16:11:48 * cdent takes away scottda's gold star
16:11:51 <scottda> rosmaita: +1
16:11:56 * mordred promises not to punch scottda
16:12:02 <scottda> ha...I was under duress...
16:12:06 <cdent> :)
16:12:12 <mordred> rosmaita: yah - what I want from the catalog is the version discovery endpoint from the service
16:12:14 <mordred> personally
16:12:30 <mordred> which is what I get from glance- thank you
16:12:34 <scottda> I'd love to get away from that with Cinder..we've just had a heated discussion at yesterday's meeting.
16:12:36 <rosmaita> :)
16:12:39 <elmiko> mixing version with service type seems a little off to me
16:12:50 <elmiko> at least from the catalog perspective
16:13:31 <scottda> I'd frankly love to expose a single endpoint and free us to bump major version for backwards-incompat changes. Like we should be doing with semver..
16:13:39 <mordred> yup. if we wanted to put version in the catalog, we'd need to essentially replace all of the version discovery endpoints with structured catalog metadata that has versions sort of like the version discovery endpoints return - which would be a complete rework of how everything works
16:13:54 <mordred> scottda: yes. execpt I want you to stop making backwards-incompat changes
16:14:00 <mordred> because they're MASSIVELY painful for users
16:14:15 <mordred> but if you must, I'd still prefer them to be listed in the version discovery system
16:14:17 <scottda> mordred: Well, we'll never deprecate old stuff..
16:14:21 <mordred> scottda: yes
16:14:23 <mordred> that's fine
16:14:34 <mordred> end-users have to deal with the pain if we don't
16:14:46 <scottda> it's kinda what microversions is supposed to allow, but people are confused, at least some cinder devs.
16:15:04 <mordred> well -- this is a whole other argument which is potentially off topic
16:15:13 <scottda> I'd really, really like to have some discussions around this at the PTG
16:15:18 <cdent> cool, I think getting this stuff in the log and into people's brains is useful for future guideline creation and other discussions. Is there a particular action we can describe for what's next, if any?
16:15:19 <mordred> scottda: +10000000000
16:15:32 <cdent> scottda: which particular "this" do you mean?
16:15:55 <scottda> API versioning, especially around major version changes (backwards-incompat)....
16:15:57 <cdent> edleafe are you going to ptg? I'm not, elmiko is not, etoews is not, as I recall.
16:16:03 <scottda> and how that relates to the service catelog
16:16:15 <edleafe> Yes, I'll be at the ptg
16:16:18 <scottda> Cinder's proliferation of endpoints is problematic, I agree.
16:16:19 <mordred> scottda: you can count on at least me to show up to such a discussion
16:16:34 <scottda> ok, at least us then.
16:16:36 <mordred> scottda: I'll be happy to energetically share opinions on the end user experience :)
16:16:54 <cdent> #action edleafe, scottda, mordred to drive some dicussion about api versioning at ptg
16:17:12 <mordred> \o/
16:17:14 * dtroyer will provide moral support
16:17:24 <scottda> yeah, not sure how cross-project discussions at ptg work. Is there some etherpad to sign up for a room or something?
16:17:45 <cdent> any action to make about service-types-catalog?
16:18:33 <cdent> I'll take that as a "we'll think about it until we figure something out"
16:18:36 <cdent> next topic
16:18:45 <cdent> #topic new biz: status of the glance change?
16:18:49 <cdent> rosmaita: floor?
16:18:58 <rosmaita> ok, well ...
16:19:24 <rosmaita> i put an item on the QA team agenda to ask for an "official" decision about whether they would accept the tempest patch
16:19:45 <rosmaita> http://lists.openstack.org/pipermail/openstack-dev/2017-January/109965.html
16:20:08 <rosmaita> unfortunately, i had teh meeting time wrong (they alternate 9 & 17 UTC) and missed it
16:20:25 <rosmaita> got one response on the ML, to which i responded thjis morning:
16:20:33 <rosmaita> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110018.html
16:21:20 <rosmaita> i tried to clarify that yes, we are aware that the change we are making has an incompatibility, but we want to do it anyway
16:21:29 <rosmaita> and that we have community support for the change
16:21:46 <rosmaita> but i'm not sure what the next move is here
16:22:16 <cdent> yeah, I stumbled at that point too
16:22:30 <mordred> hrm. it's a breaking change, but it's also a bug fix
16:23:08 <rosmaita> yes, and we've tried to minimize impact by the way the default image visibility will be set
16:23:34 <mordred> oh - wait - I was thinking of the wrong thing. this thing you're doing I think is completely fine
16:23:43 <rosmaita> i guess i need to get a clear statement from the QA team that they refuse to allow this change, period
16:23:58 <cdent> there's a similar desire to fix a thing in keystone that is somewhat backward incompatible and I left a comment that I think is appropriate here: https://bugs.launchpad.net/keystone/+bug/1654084/comments/8
16:23:58 <openstack> Launchpad bug 1654084 in openstack-api-wg "Listing resources with invalid filters should result in a 400" [Medium,In progress] - Assigned to Ed Leafe (ed-leafe)
16:24:13 <jokke_> We had timely heated discussion about this within the glance community and what the user impact will be and how we minimalize the impact to the smallest possible inconvenience
16:24:18 <cdent> we don't want to lose sight of the goal: make things better for users
16:24:19 <rosmaita> mordred: not surprised you forgot, this has been dragging on for a long time ... you gave your OK back in June, i think!
16:24:38 <edleafe> The only stopper is the Tempest test, no?
16:24:41 <cdent> yes
16:24:53 <rosmaita> yep
16:25:03 <edleafe> And it seemed (IMO) that the logic in the test was flawed
16:25:04 <cdent> and it appear that only one tempest core opposed, another is okay
16:25:22 <edleafe> i.e., based on an incorrect assumption
16:25:38 <mordred> yah.I think it's a much better user experience, and the way in which it's breaking things is _way_ easier to deal with than the mass of other api breaking changes that are rolling out
16:25:42 <stevelle> we have two cores who are opposed, to be precise
16:26:25 <rosmaita> just noticed that jordan gave it a +2
16:26:28 <rosmaita> https://review.openstack.org/#/c/414261/
16:26:28 <cdent> ah, thanks stevelle, I was counting comments and votes that I've superficially seen, not all commentary
16:26:45 <mordred> so - fwiw, the primary role of the TC is actually to mediate intractible disagreements between projects
16:26:51 <cdent> #link the glance change to tempest https://review.openstack.org/#/c/414261/
16:26:59 <mordred> I can think of almost no times the TC has been asked to do so
16:27:07 <cdent> heh
16:27:13 <mordred> but if it can't be worked out, it's completely fair and in scope to raise it at the TC level for guidance
16:27:20 <edleafe> mordred: agreed
16:27:48 <rosmaita> jordan's comment on the patch is "I am ok with this. I've read the several discussions about this, it's not worth blocking and fighting with the Glance team, imo. I am not sure image sharing is widely used anyway."
16:27:48 <hemanthm> ++ mordred
16:27:49 <cdent> It's interesting that this is intractable (from an observational/intellectual standpoint).
16:29:07 <cdent> It seems like with jordain's vote that it is close, and maybe it's on its way to being resolved? Is there anything in the meantime that the api-wg can/should do to help (we've already put our stamp of approval on it)?
16:29:18 <cdent> s/ain/an/
16:29:59 <rosmaita> no, i can maybe follow up with the QA PTL and ask him to get some more QA/tempest cores to look at it?
16:30:07 <cdent> that seems like a good plan
16:30:14 <rosmaita> and then if we can't get it merged, take it to the TC
16:30:19 * cdent nods
16:30:34 <cdent> any further commentary before moving on?
16:30:34 <rosmaita> ok, thanks everyone
16:31:05 <cdent> #topic new biz: open mic
16:31:05 <rosmaita> quick etiquette question
16:31:14 <cdent> go for it
16:31:28 <rosmaita> is it ok if i send a personal message to QA PTL, or should i do it on the ML?
16:31:38 * cdent defers to old man mordred
16:32:21 <edleafe> I generally prefer the ML for things like that.
16:32:37 <elmiko> default to open ;)
16:32:52 <rosmaita> sounds good, thanks
16:32:53 <edleafe> I don't want to be appearing to get around things by appealing to personal relationships
16:32:54 <cdent> politically I think everything should be on the ML, socially it has often proven otherwise. In this case I don't think it makes much difference.
16:33:03 <elmiko> edleafe++
16:33:16 <cdent> okay; anyone have a new non-agenda open mic topic they'd like to raise?
16:33:36 <rosmaita> i agree open is better, i just don't want it to appear like a "power cc:"
16:34:04 <elmiko> rosmaita: yeah, that's fiar
16:34:08 <elmiko> fair even
16:34:40 <edleafe> BUt to be fair, most people don't like me, so I can't use personal appeal as an advantage :)
16:34:41 <scottda> If noone else has a topic, what's the next step on discussion of versioned endpoints at the PTG? An ML post?
16:34:49 <elmiko> edleafe: LOL
16:34:54 <cdent> scottda: yeah, that seems like a good idea
16:35:11 <jokke_> edleafe: it's good that I'm not the only one :D
16:35:21 <edleafe> jokke_: heh
16:35:34 <scottda> I'm not sure I have as much info on this as others, but I'll do it if noone else wants to.
16:35:42 <cdent> scottda: including amongst your other questions: is there an etherpad for this sort of thing yet?
16:35:59 <cdent> if you start the ball rolling it will accumulate info
16:36:25 <scottda> cdent: I thought there was, but not sure. diablo_rojo told me that there were fishbowl rooms and she thought service teams would have rooms on mon-tues..
16:36:43 <cdent> there's this message on a related topic from long ago: http://markmail.org/message/o4k7wd7vqxon2ypk
16:36:45 <scottda> so for cross-project she *thought* cinder would have a large-ish room available.
16:36:57 <cdent> "In a perfect world, every endpoint would return the same type of resource - most likely the versions resource as described in the API WG Microversions spec."
16:37:31 <scottda> cdent: OK, I'll send out an ML post that we want to discuss how to get to that perfect world...
16:37:37 <scottda> without breaking existing users.
16:38:00 <cdent> #action scottda to send out email to get things started for consistent versioned endpoints
16:38:03 <cdent> thanks
16:38:12 <scottda> np
16:38:16 <cdent> #topic guidelines
16:38:27 <cdent> #link lots of guidelines https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:38:55 <cdent> I'm not aware of anything that's ready to freeze? edleafe has added a ton of good stuff that still needs a bit more review and revision
16:39:14 <cdent> sigmavirus has the pagination thing in progress, on which there's a bit of discussion about "tone"
16:39:28 <edleafe> cdent: yeah, I've gotten some good feedback, but would like a little more if possible
16:39:31 * sigmavirus hasn't had a minute to change the tone
16:39:50 <edleafe> sigmavirus: I can take a whack at it if you like
16:39:50 <cdent> and the capabilities guideline is still moving forward but not really achieving consensus
16:40:09 <sigmavirus> edleafe: gopher it :)
16:40:17 <edleafe> sigmavirus: kewl
16:41:15 * cdent misses gopher
16:41:40 <cdent> only gopher 1 though, gopher 2 was nightmare
16:41:50 <sigmavirus> let's make gopher3
16:42:00 <cdent> it'll be SO MUCH BETTER
16:42:03 <sigmavirus> layer it on top of quic or something for giggles
16:42:08 <cdent> exactly
16:42:32 <elmiko> lol
16:42:33 <cdent> so I wonder if we should talk a bit about the capabilities guideline
16:42:47 <cdent> #link capabilities guideline: https://review.openstack.org/386555
16:43:07 <cdent> Does it even fit in the api-wg?
16:43:50 <sigmavirus> Are we even capable of having this discussion? ;) ;)
16:43:54 <cdent> ikr
16:44:14 <cdent> I'm forever optimistic about being able to have whatever conversation we want
16:44:14 <elmiko> hehe
16:44:17 <edleafe> cdent: well, yeah, if it is determined that APIs should support capability discovery
16:44:57 <elmiko> i think it fits for us to discuss the details surrounding the api impl, but i'm not sure about the api-wg commenting on the content of the capabilities proposal
16:45:01 <cdent> there's something about capabilities discovery that makes me feel really squeamish and I cannot put my finger on why
16:45:02 <edleafe> I would first like to define exactly what information this API should return
16:45:03 <scottda> It should certainly be uniform across services, so this would be the place to make that better.
16:45:22 <scottda> otherwise, we'll get a hodge-podge
16:45:28 <elmiko> scottda: +1
16:45:39 <cdent> yes, that's very true
16:46:12 <elmiko> i'm just not sure we need to weigh in, in an official api-wg capacity, about whether capabilities is a good idea or not.
16:46:20 <cdent> mordred: are you still around? from the world of shade and cloud-config etc can you comment on the need for capabilities discovery?
16:47:19 <cdent> elmiko: part of the reason I think we _might_ want to weigh in is because of what I said in one of my comments on the review: if you need it at the instance level than the resource representations aren't great
16:47:35 <cdent> and we should aspire to good resource representations rather than bandaids to fix them
16:48:24 <elmiko> cdent: and i think that is fair, we are still discussing good api design. i just meant from a perspective of "capabilities are bad/good" kinda thing.
16:48:56 <cdent> asking a cloud if it is capable of function X is much different from asking an instance if it is capable of function X
16:48:57 <edleafe> cdent: why wouldn't a user want to know about what they can/can't do with an instance?
16:49:16 <cdent> they should know by looking at the instance itself, not another URL
16:49:25 <edleafe> cdent: but johnthetubaguy's comment was that this was always for an authenticated request
16:49:33 <edleafe> cdent: i.e., it had a user's scope
16:49:51 <cdent> sure but /capabilities/volume is about this cloud
16:50:10 <cdent> and /volume/id/capabilities is about this instance
16:50:15 <cdent> the latter seems off to me
16:51:07 <edleafe> the latter seems more like it would be better served by a --dry-run sort of construct
16:52:32 <cdent> in fact, ideally I would act a service about its capabilities, I'd ask a cloud about the capabilities of all its services
16:52:37 <cdent> sigh
16:52:45 <cdent> s/would act/wouldn't ask/
16:52:45 <edleafe> "Does this cloud support volume deletion?" is different than "Can I delete this volume?"
16:53:13 <cdent> that latter question should be answered by a link rel in the representation of the volume at /volume/id
16:53:18 <edleafe> but they are both being called 'capabilities'
16:53:32 <cdent> right, and that seems incorrect (to me)
16:55:18 <edleafe> me too
16:55:40 <cdent> anyone else want to weigh in?
16:55:56 <elmiko> i'm kind atorn
16:56:04 <scottda> yeah, me too
16:56:19 <scottda> and I've ping'ed dulek who wrote the patch, but no reply.
16:56:22 <elmiko> i can see the wisdom in querying the cloud for capabilities, but i wonder if the users are looking for something more detailed than that
16:56:52 <scottda> Well, the cloud may have capabilities that an individual user doesn't have access to....
16:57:04 <scottda> some 0f that, for volumes, can be in volume-type
16:57:09 <scottda> i.e. backup
16:57:11 <elmiko> at the same time, in the case of the delete volume example, why would you query to find out if you could delete a volume? wouldn't you just try it on a cloud that has deletions, and then respond accordingly to the response from the service?
16:57:49 <edleafe> elmiko: because some things are async
16:58:05 <elmiko> edleafe: good point
16:58:18 <cdent> Since we only small number of minutes left, anyone who is interested please add more commentary on the review: https://review.openstack.org/386555
16:58:21 <cdent> last topic
16:58:27 <cdent> #topic: bug review
16:58:54 <cdent> we've had at least one new bug but it's been addressed almost as quickly as it was created (thanks edleafe!): https://review.openstack.org/417441
16:59:01 <elmiko> this is part of the reason i don't want to be in the middle of the design process about capabilities, i'm happy to give advice about the api design, but i don't have a strong enough grasp on the end goal to give good advice on the proposed solution
16:59:07 <cdent> but that leaves a lot of older bugs languishing
16:59:14 <cdent> if you have time interest please have a look
16:59:30 <cdent> #link bugs: https://bugs.launchpad.net/openstack-api-wg
17:00:03 <edleafe> Most of the bugs are TODOs, so it doesn't take a lot to fill in the guidelines for the missing TODO
17:00:17 <cdent> anyone itching to newletter? if not i'll ping people to review my edits later
17:00:31 * elmiko checks
17:00:33 <cdent> thanks everyone for coming, nice to see so many people
17:00:35 <elmiko> nope, no itch
17:00:39 <elmiko> ;)
17:00:43 <cdent> conversation continues in #openstack-sdks
17:00:47 <cdent> #endmeeting