16:00:00 <cdent> #startmeeting api-wg
16:00:01 <openstack> Meeting started Thu Jan  5 16:00:00 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:04 <openstack> The meeting name has been set to 'api_wg'
16:00:09 <elmiko> hola
16:00:14 <cdent> hello! who has shown up from the api-wg meeting?
16:00:14 <rosmaita> o/
16:00:23 <sigmavirus> hello, e'rybody!
16:00:27 <cdent> #chair elmiko etoews edleafe
16:00:28 <openstack> Current chairs: cdent edleafe elmiko etoews
16:00:53 <cdent> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:01:07 <cdent> There's, like, actual stuff on the agenda this week!
16:01:08 <etoews> o/
16:01:16 <cdent> #topic previous action items
16:01:29 <cdent> #link last meeting http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-12-15-16.01.html
16:01:37 <elmiko> ooh neat
16:01:43 <cdent> agitating about capabilities (done)
16:02:42 <cdent> ed making some new guidelines on booleans and state status (done)
16:03:11 <cdent> #topic Glance Community Images and the API stability guidelines (rosmaita)
16:03:27 <cdent> #link https://etherpad.openstack.org/p/glance-ocata-community-images-api-stability
16:03:29 <cdent> take it away rosmaita
16:03:33 <rosmaita> thanks
16:03:38 <rosmaita> #link https://etherpad.openstack.org/p/glance-ocata-community-images-api-stability
16:03:51 <rosmaita> you may have seen the item on the ML before the holidays
16:04:07 <rosmaita> the etherpad linked above has the basic info about my question
16:04:28 <rosmaita> probably best to read through the etherpad?
16:04:51 <elmiko> reading now
16:05:11 * rosmaita sits on his hands
16:05:15 <elmiko> lol
16:06:04 <cdent> I'l start by saying that I don't agree with the evaluating api changes document, but it is the "standard" that we have.
16:06:52 <sigmavirus> cdent: what don't you agree with?
16:07:08 <sigmavirus> It's also not as if all standards are written in stone
16:07:09 <cdent> nor do I agree that tempest maintainers shoud be the arbiters of what is correct behavior in an api
16:07:17 <elmiko> rosmaita: question about the visibility stuff, are these values in the body response?
16:07:35 <sigmavirus> elmiko: they're both request parameters and response body parameters iirc
16:07:42 <cdent> but I make both comments as an independent observer, not as API-WG core™
16:07:48 * sigmavirus is here with Glance and also not with Glance ;)
16:07:48 <elmiko> sigmavirus: ack, thanks
16:07:55 <elmiko> nice
16:07:58 <rosmaita> elmiko: what sigmavirus said
16:08:23 * stevelle is like sigmavirus
16:08:27 * sigmavirus is also here to discuss pagination
16:08:35 <elmiko> as to #1, i don't see why that is not possible
16:08:50 <etoews> the way i read it is that the tempest maintainers are being the arbiters of backwards incompatible changes but i may not have all of the context
16:09:01 <elmiko> if you are rev'ing the version anyways, seems ok to expand those definitions
16:09:05 <sigmavirus> elmiko: I agree. It's an API expansion which I always  understood to be acceptable
16:09:11 <sigmavirus> etoews: agreed with you
16:09:33 <rosmaita> elmiko: i bring it up, becase a literal reading of the guideline seems to rule it out
16:10:06 <elmiko> correct me if i'm wrong, but i thought with the new versioning changes we are bumping the major release for each openstack version. so, wouldn't that dictate that backward incompat changes are acceptable?
16:10:33 <sigmavirus> elmiko: which versioning changes?
16:10:35 <elmiko> rosmaita: ok, let me re-review the guidance
16:10:40 <sigmavirus> as in Glance 13.0.0 to 14.0.0?
16:10:55 <elmiko> sigmavirus: yeah, not exactly new. bad phrasing on my part.
16:11:15 <cdent> elmiko: I don't think that applies to exposed HTTP APIs
16:11:24 <elmiko> cdent: ah
16:11:35 <sigmavirus> elmiko: right, so I've disagreed with the way openstack versions and does "semantic versioning" for a long time but that does not really follow convention or defacto rule son backwards compat
16:11:59 <elmiko> yeah, certainly seems that way
16:12:06 * edleafe is back
16:12:41 <cdent> rosmaita: can I present a summary to you so you can tell me if my brain is wrong?
16:12:42 <sigmavirus> elmiko: yeah, the APIs are versioned independently of the software
16:12:51 <rosmaita> cdent: fire away!
16:12:54 <sigmavirus> cdent: that'd probably benefit everyone :)
16:13:38 <cdent> Before 2017 there was a long an arduous debate about how to deal with visibility. That reached a conclusion that didn't make everyone happy but at least made everyone not want to burn it all to the ground. Then
16:14:10 <cdent> implementation of that solution has resulted in a conflict with the norms enforced in tempest
16:14:25 <cdent> because behavior has changed
16:14:58 <cdent> a proposal to work around that changed behvior by changing the test has been rejected as that is, in fact, a work around, and as such violates proper backwards compatibility
16:15:13 <sigmavirus> cdent: correct thus far
16:15:29 <cdent> thus we are now trying to decide which norms to follow, which to break, or just some way to move foward
16:15:41 <rosmaita> rem acu tetigisti
16:15:53 <stevelle> it isn't terribly important, but I'll point it out: the tempest test in question was added during Ocata
16:16:19 <cdent> If that's all correct, my only source of confusion is really around: what are we trying to decide? What are our options? Do we want to/think we can tell tempest to do things differently?
16:16:39 <rosmaita> here's the situation
16:16:57 <cdent> stevelle: I think that's a pretty important consideration
16:17:02 <rosmaita> the specific test breaks if you include an optional 'visibility' when creating an image
16:17:04 <cdent> (the age of the test)
16:17:15 <rosmaita> if you don't include the optional 'visibility', it would pass
16:18:00 <rosmaita> so our opinion is that the change is "mostly" backward compatible
16:18:16 <rosmaita> (or *my* opinion, anyway)
16:18:16 <sigmavirus> cdent: specifically if you say you want your image to have "visibility = private" and then try to share it, that's what breaks
16:18:17 <edleafe> rosmaita: was 'visibility' a valid param in the past?
16:18:22 <sigmavirus> edleafe: yes
16:18:36 <edleafe> sigmavirus: then it breaks the API
16:19:06 <rosmaita> edleafe: the break doesn't happen in the creation of the image
16:19:07 <elmiko> is there an issue with simply expanding the tempest tests for visbility, or does that run against the backward compat issue?
16:19:07 <stevelle> edleafe: it was default to private, and the other choice (public) was limited by to admin by RBAC by default
16:19:09 <edleafe> ...or at least the tempest test
16:19:17 <rosmaita> it happens when you try to add a member to the image
16:19:18 <etoews> i don't suppose you have any real data on who is depending on the current behaviour in real life (non-tempest-wise)
16:19:21 <sigmavirus> edleafe: I absolutely sympathize with that, but I think along those lines that this will break the API regardless based on what tempest suggests we do
16:19:24 <clarkb> random drive by comment, these changes are particularly bad for users when there is no way to discover whether or not such a param is valid from the outside
16:19:47 <rosmaita> clarkb: the param is valid
16:19:51 <clarkb> if I have been using it for years then all of a sudden it stops working on some portion of my clouds then I have a bad day
16:20:10 <rosmaita> what happens is that what you can do with your image depends on what visibility you give it
16:20:12 <sigmavirus> edleafe: a similar test could create the image with visibility "private", add an image and then assert the visibility is still private afterwards. The "workaround" the tempest team suggested will break that
16:21:20 <sigmavirus> That's not meant to justify anything, just to give perspective that really the whole thing can be considered breaking, especially provided a user isn't already familiar with glance or changes introduced in ocata
16:21:38 <cdent> my understanding from the pre-2107 debate was that there was awareness that this chang was going to have user impact but that it was an important change to make a better future, the past was a bug, and this is pain that just needs to be eaten, now.
16:21:40 <edleafe> Well, unless the existing test is invalid or incorrect in what it tests (which happens a lot), then the change isn't backwards compatible
16:21:48 <sigmavirus> If a user creates the image, adds a member to it, and then sees that it's suddenly marked as "shared" instead of "private" I have to wonder if they'll be surprised by that or not
16:22:14 <cdent> If my statement is correct, then I would think that changing tempest is the right thing to do.
16:22:19 <stevelle> edleafe: see above, where it is not claimed to be backwards compatible
16:22:26 <clarkb> rosmaita: right my specific thing is don't change behavior without any way of making it discoverable between clouds that otherwise appear the same to the user (which I think is the case here if I am reading about why tempest fails. Yesterday it was fine, today not, clouds look the same)
16:22:26 <stevelle> claimed to be mostly*
16:22:31 <elmiko> cdent: +1
16:23:05 <sigmavirus> clarkb: so you're right. Since Glance doesn't have microversions, there's no way for a user to get yesterday's behaviour back
16:23:17 <rosmaita> cdent: i agree with your "my understanding" comment above
16:23:21 <sigmavirus> But Glance will report that the version has changed which is a pittance of a way to discover the new version
16:23:24 <sigmavirus> (or changes)
16:23:44 <etoews> sigmavirus: if you add a member, how could it be considered anything but shared? it's literally being shared.
16:23:47 <edleafe> sigmavirus: this would be a non-issue with microversions
16:23:54 <sigmavirus> etoews: because right now it remains private
16:23:59 <sigmavirus> edleafe: agreed
16:24:03 <clarkb> sigmavirus: right and that to me is the actual major issue with these changes
16:24:10 <clarkb> sigmavirus: it makes using openstack as a user incredibly frustrating
16:24:26 <sigmavirus> clarkb: I'm 100% with you
16:24:36 <sigmavirus> We have a vocal minority in glance that's opposed to microversions
16:24:49 <edleafe> So it's a trade-off of one frustrating thing for another potentially frustrating thing
16:24:52 <rosmaita> clarkb: the tradeoff is that the visibility semantics will now make sense
16:25:02 <edleafe> just different users being frustrated
16:25:10 <rosmaita> edleafe: +1
16:25:14 <stevelle> edleafe: agreed
16:25:17 <sigmavirus> edleafe: correct. And don't get me wrong. I absolutely think this behaviour is a huge improvement
16:25:18 <cdent> the theory is: fewer users being frustrated
16:25:50 <edleafe> cdent: fewer is better, unless it's in a serious way
16:25:51 <clarkb> rosmaita: edleafe yes but the impact to someone who is now broken in production and has no clue why vs someone learning funky semantics vs just telling the user whats up properly are not the same
16:26:11 <edleafe> clarkb: makes sense
16:26:12 <cdent> we need to timebox this in some fashion.
16:26:22 <sigmavirus> Additional consideration: This change also auto-migrates existing images
16:26:35 <sigmavirus> So private images with members will automagically become shared after this change
16:26:46 <rosmaita> clarkb: the change is designed so that if you use defaults, everything works the same
16:26:57 <rosmaita> so don't anticipate problems in production systems
16:27:00 <sigmavirus> ^ is very true
16:27:19 <etoews> that's significant
16:27:20 <cdent> From what I recall the discussion of the details of the change were _well_ trod when making the spec and discussing the email. We don't want to revisit that now.
16:27:23 <edleafe> sigmavirus: how serious is that?
16:27:34 <edleafe> sigmavirus: IOW, is it a potential security hole?
16:27:43 <sigmavirus> edleafe: is what a potential security hole?
16:27:47 <sigmavirus> auto-translating image visibility?
16:27:48 <stevelle> edleafe: it is backwards compatible
16:27:49 <sigmavirus> I think it is
16:27:54 <edleafe> sigmavirus: yeah
16:28:00 <etoews> glance is clearly making a real effort to mitigate the risk
16:28:13 <edleafe> E.g.: I made this private, but suddenly it's shared
16:28:14 <clarkb> (I don't intend to retrod anything, just want to point out that to me as a user that is the actual concern, I think improving APIs is great we just need to be better and communicating to users how things have changed across clouds)
16:28:16 <sigmavirus> copy-paste wrong image-id and now you've shared an image, but that's the same thing as the current behaviour
16:28:19 <sigmavirus> so it's not a new risk
16:28:26 <sigmavirus> clarkb: agreed
16:28:40 <sigmavirus> edleafe: right now "private" can mean "private" or "private with members == shared"
16:28:54 <rosmaita> that's the key problem, i think
16:29:06 <rosmaita> 'private' != "private"
16:29:16 <edleafe> sigmavirus: I only ask because unless it would do something horribly nasty, it sure sounds like this change would be a big improvement
16:29:16 <elmiko> yeah, that seems imprecise
16:29:44 <cdent> So let me ask again: How can the api-wg help in this matter, now?
16:30:03 <rosmaita> the issue is whether this change would violate the guidelines
16:30:18 <jokke_> edleafe: really only nastyness it does is that it breaks one very precise tempest test
16:30:19 <rosmaita> the -1 on the tempest patch says it does
16:30:20 <sigmavirus> cdent: I think Glance is just stuck on technicalities with guidelines and dealing with Tempest's/QA Team's feedback
16:31:11 <edleafe> jokke_: which means it doesn't do anything nasty to actual users
16:31:16 <cdent> a) they are just guidelines, they are violated all the time b) the existing semantics are (to me) a bug, at least mentally a security bug, so gravy
16:31:43 <cdent> where "gravy" means "the guidance approves"
16:31:59 <elmiko> i tend to agree with cdent
16:32:03 <edleafe> So could a case be made that the existing Tempest test suffers from the same imprecision?
16:32:25 <jokke_> edleafe: and anyone who has bee creating images with --visibility='private' will need to first change the image to shared before running the member actions
16:32:29 <edleafe> (as the private has more than one meaning)
16:32:32 <sigmavirus> edleafe: the current test represents a potential real usage of Glance
16:32:39 <rosmaita> edleafe: what i'd say is this: the existing test explicitly says to create a private image
16:32:48 <rosmaita> then, when you share it, it fails, as it should
16:32:57 <rosmaita> (though, currently, it would succeed)
16:33:08 <jokke_> cdent: we've actually had multiple bugs opened complaining that private is really not private
16:33:26 <rosmaita> the test would succeed if you (a) created an image with no viz specified, or (b) created it with viz == shared
16:33:27 <edleafe> So it currently passes on something that should really be a failure?
16:33:29 <sigmavirus> we also don't recommend that users specify visibility necessarily but allow it
16:33:41 <sigmavirus> edleafe: ugh that's half-true, I guess?
16:33:45 <jokke_> edleafe: correct
16:33:51 <cdent> Yeah sounds like the test is pretty much wrong
16:33:55 <sigmavirus> I mean presently with only two visibilities, a failure is hard to quantify
16:33:59 <stevelle> so as an action, either replies in support of changing the tempest test to support the spec as written, or responses to the tempest change may be helpful
16:34:01 <sigmavirus> Because public visibility's members don't matter
16:34:08 <sigmavirus> And I don't think you can add members to "public" images now
16:34:13 <sigmavirus> So you have to have a private image to add a member
16:34:15 <jokke_> edleafe: not by design should fail but by any basic logic should fail
16:34:18 <cdent> can someone # link the review of the tempest in here please?
16:34:20 <sigmavirus> So it's a failure and it's a not failure too
16:34:21 <edleafe> Then I think it's clear that the test should be changed if it passes on a disallowed action
16:34:23 <stevelle> https://review.openstack.org/#/c/414261/
16:34:26 <cdent> thanks
16:34:51 <sigmavirus> Glance's visibility logic is just really bad presently
16:34:55 <cdent> #action (everyone) go comment on tempest test change https://review.openstack.org/#/c/414261/
16:34:56 <etoews> i abhor backwards incompatible changes but the current behaviour really is a bug and flat out needs to be fixed. i lean towards it being acceptable.
16:34:57 * edleafe doesn't hold tests as sacred
16:34:59 <cdent> we need to move on
16:35:13 <rosmaita> ok, thanks everyone
16:35:18 <elmiko> sigmavirus: seems like it
16:35:28 <rosmaita> i think this has been helpful, let's see what the QA team says
16:35:34 <cdent> that was fun
16:35:37 <sigmavirus> (That's not the only thing that has that description in glance though =P)
16:35:37 <jokke_> thanks all ... we really appreciate your time on this!
16:35:50 <cdent> #topic open mic
16:36:08 <cdent> resource actions came up again shortly before christmas
16:36:19 <elmiko> sigmavirus, rosmaita, jokke_, thanks for bringing it up =)
16:36:20 <cdent> #link resource actions email: http://lists.openstack.org/pipermail/openstack-dev/2016-December/109136.html
16:36:42 <cdent> the usual three perspectives on that were represented, with the usual lack of consensus
16:36:59 <cdent> I mention it here because it is something we probably need to continue to think about as it is going to keep coming back up
16:38:30 <cdent> thoughts for the record? or if you want to add to that thread, that would be cool. Or if you want to resurrect the guideline process that would be cool too.
16:38:40 <cdent> If not, I'll move on.
16:38:42 <edleafe> I added my thoughts to the thread
16:39:06 <cdent> Who added the boston cfp link?
16:39:11 <etoews> moi
16:39:18 <cdent> #link boston cfp: https://www.openstack.org/summit/boston-2017/call-for-presentations/
16:39:37 <etoews> just as a reminder that we need to do the usual song and dance for boston
16:40:04 <cdent> Not confirmed but I predict I will not be there (I won't be at ptg either).
16:40:30 <edleafe> I will be at ptg, but boston is still a question mark
16:40:55 <etoews> both are questionable for me as well
16:41:08 <cdent> elmiko?
16:41:28 <elmiko> i highly doubt i'll be able to attend, unless i pay my own way there
16:42:11 <elmiko> maybe, if i got a paper accepted about the stuff i'm currently working on, but it's kinda removed from the openstack world. sadly
16:42:30 <cdent> next open mic topic: Do we want to have a process/discussion about setting some 2017 goals, or shall we go with the flow?
16:43:10 <edleafe> You mean like New Years resolutions? :)
16:43:14 <elmiko> hehe
16:43:14 <cdent> The world at large thinks we are doing a pretty good job and not overreaching, so the status quo may be just fine
16:43:17 <cdent> pretty much yeah
16:43:23 <cdent> things we plan to do but don't
16:43:36 <elmiko> hmm, given that feedback cdent, go with the flow seems appropriate
16:43:49 <elmiko> i like the idea of setting some goals
16:43:50 <etoews> our new year's resolution is to maintain the status quo
16:43:54 <edleafe> We don't have any huge gaping voids that we're aware of, so the flow seems right
16:43:58 <elmiko> etoews: LOL +1
16:43:59 <sigmavirus> but that's no fun
16:44:09 <cdent> my feelings exactly sigmavirus
16:44:12 <sigmavirus> always be agitating
16:44:16 <edleafe> ok, maintain the status quo, but lose 10 pounds
16:44:16 <cdent> that too
16:44:36 <elmiko> our plan for 2017 is to increase overreach?
16:44:43 * sigmavirus wonders if there is weight gain associated with working on OpenStack like there is with college
16:44:48 <cdent> I personally think we can do more on the aspirational side of thing, but some people think that would be overreach
16:44:56 <elmiko> sigmavirus: don't even get me started...
16:45:00 * rosmaita has experienced the OpenStack weight gain
16:45:10 <cdent> metoo@aol.com
16:45:15 <sigmavirus> cdent: aspirational *ideas* wouldn't be bad
16:45:15 <elmiko> haha
16:45:33 <sigmavirus> (Says the person including them in his present review)
16:45:39 <etoews> i think one the real issues around this is that we don't necessarily have the bandwidth to take action on the aspirations.
16:45:42 <sigmavirus> (totally not a shameless plug right there)
16:45:53 <elmiko> etoews: +1
16:46:00 <edleafe> etoews: true that
16:46:04 <sigmavirus> etoews: but I thought we were here to lead other's thoughts
16:46:12 <etoews> heh
16:46:13 <sigmavirus> thought leaders don't take action. They come up with actions for others
16:46:16 <cdent> one thing we could do is propose work/issues for the arch-wg around api stuff
16:46:22 <cdent> jinx!
16:46:24 <etoews> to the twitters!
16:46:45 * sigmavirus lies face in palm
16:46:48 <cdent> anyway, don't need to do anything immediately, another one for the "think about" queue
16:46:57 <cdent> #topic guidelines
16:47:16 <cdent> #link guidelines https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
16:47:17 <cdent> we have some
16:47:37 <cdent> but I don't reckon any are ready for freeze (due to xmas)
16:47:50 <edleafe> yeah, I'd like further review
16:47:56 <cdent> the capability one had a lot of discussion in the nova-api meeting recently:
16:47:58 <sigmavirus> I was wondering if people had comments on edleafe's comment on the pagination review
16:48:05 <cdent> #link capability in nova-api: http://eavesdrop.openstack.org/meetings/nova_api/2017/nova_api.2017-01-04-13.00.log.html#l-59
16:48:05 <edleafe> I just kind of threw some of those out there for others to pound on
16:48:22 <edleafe> sigmavirus: comments on comments?
16:48:33 <sigmavirus> I don't doubt that having "last" is expensive for some projects, but I wonder if there needs to be mention of optional components on something that's purely aspirational
16:49:06 <cdent> people like clarity, ed's comment corresponds to the one I made earlier about optionality
16:49:28 <cdent> some of those are MUST and some are MAY
16:49:40 <edleafe> sigmavirus: I think that someone looking at these as guidelines will try to copy them as closely as possible. It's good to let them know where the pitfalls may lie
16:49:41 <sigmavirus> Sure, I thought I had expanded on that well enough
16:50:11 <cdent> sigmavirus: i haven't looked at version 4 yet
16:50:19 <sigmavirus> edleafe: sure, I just think that last tends to be more useful than folks reckon and making it optional will introduce inconsistency where Cinder always includes it and NOva doesn't because it's optional
16:50:38 <etoews> i think we can just workflow+1 https://review.openstack.org/#/c/411391/
16:50:41 <sigmavirus> I don't know that we want to allow that kind of problem
16:50:57 <sigmavirus> We could just not recommend "last" at all
16:51:02 <edleafe> sigmavirus: sure, but the reason for paginating in the first place is not having to pull large amounts of data
16:51:19 <cdent> etoews: go for it
16:51:37 <stevelle> I think it is helpful to offer explicit stretch goals, like last, but it has to be clear there is no expectation. For those that opt in, it lets them standardize which is helpful.
16:51:59 <edleafe> stevelle: that's pretty much what I feel
16:51:59 <sigmavirus> edleafe: agreed. I just feel like there are absolutely ways around pulling large amounts of data to provide "last"
16:52:47 <stevelle> using the right data structures, ^
16:52:47 <edleafe> sigmavirus: sure, but with a million records, it can be tough to find the one that's 30 from the end :)
16:53:16 <etoews> cdent: ermmmm...apparently i can't workflow+1 anymore...
16:53:26 <edleafe> ...and do that with every hit on the link
16:53:43 <edleafe> etoews: need +2s first?
16:53:51 <elmiko> etoews: +1 on wf for that
16:54:05 <etoews> i can't even +2 :P
16:54:06 <sigmavirus> edleafe: yeah I think if you're only considering pulling it from the database dynamically every time, you'll always have terrible API performance around your pagination
16:54:35 <cdent> etoews: are you logged in as your usual person?
16:54:40 <edleafe> sigmavirus: and if you're not pulling it every time, it will be stale and pretty much useless
16:55:05 <cdent> edleafe: that's categorically not true
16:55:17 <sigmavirus> I disagree strongly, but we have 3 conversations happening right now
16:55:18 <edleafe> sigmavirus: if you want, I can post an update that adds language around last
16:55:18 <cdent> but openstack has little experience with effective caching and caching namespaces
16:55:26 <etoews> cdent: oops. guess not.
16:55:32 <sigmavirus> I guess large non-OpenStack APIs that do Last consistently and correctly and usefully are just wrong
16:55:55 <sigmavirus> (or they don't exist and I'm imagining having worked on them)
16:56:11 <cdent> so I would _love_ to have a discussion about how openstack is out of date in the api world, but let's leave that for another time please as we only have a few more minutes left
16:56:12 <edleafe> sigmavirus: like I said, it depends on how stale they are
16:56:23 <elmiko> cdent: LOL
16:56:39 <cdent> are there other things to contend about on the other reviews?
16:56:57 <cdent> things we know need to happen: more review on ed's strawmen for booleans and state
16:57:17 <cdent> more eyes on the capabiities review because it is being driven by nova and cinder right now and they are not the whole world
16:57:32 <cdent> and further discussion on the pagination thing so we can reach some consensus
16:57:35 <cdent> anything else?
16:57:51 <cdent> #topic bug review
16:58:04 <cdent> There is a new bug that came along today as a result of a keystone bug.
16:58:24 <cdent> #link 400 on bad query params: https://bugs.launchpad.net/openstack-api-wg/+bug/1654084
16:58:24 <openstack> Launchpad bug 1654084 in openstack-api-wg "Listing resources with invalid filters should result in a 400" [Medium,Confirmed]
16:58:46 <cdent> we have guidance on that issue for bodies, but not that easy to find on query params. that bug says we shoudl
16:58:57 <cdent> somebody want to volunteer for that?
16:59:08 <cdent> if so, assign yourself to the bug
16:59:16 * edleafe takes it
16:59:34 <cdent> any one eager on the newletter or shall I do it?
17:00:07 <cdent> Thanks to everyone for coming today, I think we've actually set some good foundation for stuff that matters for the coming year, based on the things we've disagreed about today.
17:00:09 <cdent> that's good
17:00:10 <cdent> so
17:00:12 <cdent> awesome
17:00:16 <cdent> #endmeeting