16:00:04 <lbragstad> #startmeeting keystone
16:00:06 <openstack> Meeting started Tue Oct 16 16:00:04 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'keystone'
16:00:14 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:14 <knikolla> o/
16:00:18 <lbragstad> o/
16:00:27 <wxy|> o/
16:00:49 <gagehugo> o/
16:01:21 <lbragstad> we have a lot to get through today - so we'll get started in a minute
16:01:56 <kmalloc> O/
16:02:25 <lbragstad> #topic Release status
16:02:35 <lbragstad> #info reminder that milestone 1 is going to be next
16:02:36 <lbragstad> week
16:02:51 <lbragstad> #link https://releases.openstack.org/stein/schedule.html
16:03:08 <lbragstad> #info next weeks is the deadline for specification proposals
16:03:11 <hrybacki> o/ (better channel)
16:03:13 <lbragstad> (more onthat later)
16:03:48 <lbragstad> also - it would be good to get as much community goal work squared away before next week as possibl e
16:04:20 <lbragstad> #info mutable configuration goal implementation is up for review
16:04:26 <lbragstad> #link https://review.openstack.org/#/c/585417/
16:05:14 <lbragstad> #info python3 first goal is nearly complete, and cmurphy is going to put the finishing touches on zuul changes so that keystone runs functional tests in python3
16:05:28 <lbragstad> #info the upgrade checker goal implementation is up for review
16:05:33 <lbragstad> #link https://review.openstack.org/#/c/608785/
16:05:47 <ayoung> Do I need to go more official for my 2 Feature-Bugs for Domains and Federation?
16:06:09 <ayoung> https://bugs.launchpad.net/keystone/+bugs?search=Search&field.assignee=ayoung
16:06:36 <lbragstad> what's that ayoung?
16:06:46 <ayoung> Is the bug report sufficient process, or do I need a spec?  They seem small enough, and explainable enough to me, but then I am the author
16:07:15 <lbragstad> um
16:07:16 <ayoung> er
16:07:24 <ayoung> sorry, thought that got the right set of bugs
16:07:27 <ayoung> 1 sec
16:07:36 <ayoung> https://bugs.launchpad.net/keystone/+bug/1794527  is right
16:07:36 <openstack> Launchpad bug 1794527 in OpenStack Identity (keystone) "Allow domain creation with a specific ID" [Wishlist,Incomplete] - Assigned to Adam Young (ayoung)
16:07:53 <ayoung> https://bugs.launchpad.net/keystone/+bug/1641639  is right
16:07:53 <openstack> Launchpad bug 1641639 in OpenStack Identity (keystone) "use mapping_id for shadow users" [Wishlist,In progress] - Assigned to Adam Young (ayoung)
16:07:56 <ayoung> yeah, those two
16:07:56 <lbragstad> looks like https://bugs.launchpad.net/keystone/+bug/1794527 is going to be a spec anyway?
16:08:18 <ayoung> lbragstad, I can.  It just seems like busy work.
16:08:26 <ayoung> I think I can explain it just as well in the bug
16:08:53 <ayoung> But...I thought everyone understood the use case, and I'm more interested in making that the case
16:09:06 <ayoung> a spec means spec approval process, etc
16:09:19 <ayoung> and this is more like a tool that can be used for a larger use case, but not tied to it
16:09:25 <lbragstad> since we've historically debated this case, i wouldn't mind a spec since it's more intuitive for discussion
16:09:37 <ayoung> well, it really is just a dependency for the other one
16:09:40 <ayoung> in my view
16:10:01 <ayoung> "use mapping_id for shadow users"  needs a common domain ID or the user ids change
16:10:12 <lbragstad> yeah - that's understandable
16:10:20 <lbragstad> i think specs work for this
16:10:33 <kmalloc> i honestly am fine with a spec or a bug, if it is a spec, it will need a tracking bug anyway.
16:10:34 <ayoung> these were designed to be as minimal as possible.  Spec process means we don't get it this release.
16:10:49 <lbragstad> as opposed to trying to debate the justification in bug comments and associating the two
16:11:31 <ayoung> I mean...I could have tried to slip the domain_id change into the other bug, as that is really what is needed to fix it, just figured it was clearer to pull it out into its own
16:11:46 <lbragstad> i think it should be it's own
16:11:58 <ayoung> is everyone ok with these changes?  Is there any real misunderstanding or objection?
16:12:09 <lbragstad> i need to review it again
16:12:12 <lbragstad> it's on my list
16:12:15 <lbragstad> #topic specifications
16:13:38 <kmalloc> https://imgflip.com/i/2k8jz9 <--- OBJECTION
16:13:41 <kmalloc> >.>
16:13:42 <kmalloc> <.<
16:14:08 <lbragstad> i would vote that we propose a specification for the domain id change, because that's always been a hot topic
16:14:14 <lbragstad> and it affects the API
16:14:55 <kmalloc> it's small enough i could see it being a bug alone. if it's a spec, i expect it to be very very empty
16:15:09 <lbragstad> it's the discussion that i'd like to capture
16:15:11 <kmalloc> and if people get too picky about the spec's contents, i'd be annoyed.
16:15:21 <lbragstad> that and we have specification proposed for review that attempted to do something similar
16:15:37 <kmalloc> so, ayoung can you propose a very light spec, anything that is "spec content" should be left to the side of the convo of if this is "good"
16:15:48 <kmalloc> convo about merits of the change, not the spec content
16:15:59 <kmalloc> and we should review that spec explicitly today/tomorrow
16:16:04 <kmalloc> if we are making ayoung post it
16:16:05 <ayoung> ok
16:16:17 <kmalloc> ayoung: basic justification.
16:16:27 <lbragstad> #action ayoung to propose https://bugs.launchpad.net/keystone/+bug/1794527 as a specification
16:16:27 <openstack> Launchpad bug 1794527 in OpenStack Identity (keystone) "Allow domain creation with a specific ID" [Wishlist,Incomplete] - Assigned to Adam Young (ayoung)
16:16:36 <kmalloc> please keep the bug as the tracker for it
16:16:53 <ayoung> will do
16:17:04 <lbragstad> thanks ayoung
16:17:07 <kmalloc> and if folks do not register complaints about functionality in the next couple days, I warn you, it's going to be merged :)
16:17:29 <lbragstad> if that's the case, socialize it on the mailing list so that it gets proper visibility
16:17:36 <kmalloc> #action everyone review justification of ayoung's spec (please do not nit pick the content)
16:17:45 <lbragstad> cmurphy is super busy this week
16:18:13 <kmalloc> right. this should be a quick review
16:18:29 <kmalloc> and should be the core teams #1 review target for discussion
16:18:36 <kmalloc> if there is discussion it can wait till S1 day
16:18:51 <kmalloc> if there isn't active discussion/dissent we can merge it sooner
16:18:56 <kmalloc> i expect this can land.
16:19:03 <lbragstad> rememeber that specification freeze is january 11th
16:19:24 <lbragstad> but - the earlier the better if we can helpit
16:19:29 <kmalloc> exactly
16:19:36 <knikolla> ++
16:19:37 <kmalloc> i expect there will be little dissent on this one
16:19:43 <kmalloc> it is straightforward.
16:19:58 <kmalloc> so please review it this week.
16:20:02 <lbragstad> ayoung outside of those two, do you have other specs to bring up?
16:20:18 <kmalloc> lbragstad: also, holy crap jan 11 is a ways down the road for spec freeze :P long cycle is long
16:20:23 <ayoung> I brought jamie's back to life, too
16:20:44 <lbragstad> yeah - this release is going to be a marathon
16:20:48 <ayoung> https://review.openstack.org/#/c/607346/
16:20:56 <lbragstad> #link https://review.openstack.org/#/c/607346/
16:21:01 <kmalloc> unscoped catalog
16:21:07 <kmalloc> i would love to see this.
16:21:07 <ayoung> that spec was approved, but then backlogged.  I brought it back to the front.
16:21:15 <ayoung> And its on the agenda for later, I think
16:21:17 <kmalloc> just point blank.
16:21:25 <ayoung> wanna talk it through now?
16:21:36 <lbragstad> can we circle back if we have time?
16:21:40 <ayoung> ++
16:21:51 <kmalloc> ++
16:21:55 <ayoung> just know that it is there
16:22:06 <lbragstad> ok
16:22:16 <lbragstad> ayoung looks like you have something for read-only role?
16:22:24 <ayoung> so...sort of
16:22:27 <ayoung> it is more than just that
16:22:29 <kmalloc> quick backtrack, caching is questionable in a couple ways for py3
16:22:40 <kmalloc> just fyi
16:22:45 <kmalloc> it will "work"... ish
16:22:54 <kmalloc> i need to revisit pymemcache
16:23:31 <kmalloc> ok we can move on for read-only role.
16:23:39 <ayoung> Actually, lets go in order
16:23:48 <ayoung> unscoped token...short question
16:23:57 <ayoung> I need to firgure out what to populate in that service catalog
16:24:05 <ayoung> tests do all uuids, even for names,
16:24:17 <ayoung> so I can't just strip out all but 'identity' service
16:24:24 <ayoung> which is what I was origianlly planning on doing
16:24:31 <ayoung> talked it over with jamie last night:
16:24:46 <ayoung> we don't foresee anything in the catalog for unscoped tokens but the identity services
16:24:48 <kmalloc> have services (e.g. nova) fixed thier requirement for a project id in the path?
16:24:53 <kmalloc> because i know that was an initiative
16:24:55 <kmalloc> for a while
16:25:15 <lbragstad> i don't think nova uses the project id in the path anymore
16:25:16 <ayoung> does that apply here?
16:25:21 <lbragstad> cinder does though
16:25:35 <lbragstad> wxy| opened a bug for that with system-scope
16:25:43 <ayoung> this is unscoped catalog only, so no cinder or nova uin the catalog anyway
16:25:54 <ayoung> different subject
16:26:28 <ayoung> what I need to implement is the way to extend access to the catalog API to get the right catalog for unscoped tokens
16:26:37 <kmalloc> right, but if we get to the point we're not substituting in projects into the catalog paths...
16:26:39 <ayoung> I'd like it to be something cacheable,
16:26:41 <kmalloc> we can render the same catalog
16:26:47 <kmalloc> and not care.
16:26:50 <ayoung> got it
16:27:01 <kmalloc> :)
16:27:10 <ayoung> so, I was thinking this might be a new (python) API call against the catalog backend
16:27:21 <ayoung> but...
16:27:31 <ayoung> we don't hardcode "identity" anywhere
16:27:37 <ayoung> so...should that be a config option?
16:27:49 <kmalloc> hm. no.
16:27:52 <ayoung> like "unscoped_token_services":  [identity]
16:28:03 <ayoung> then...what is the "right" way in our world?
16:28:07 <kmalloc> you can extend the service data in the api
16:28:19 <kmalloc> and add "unscoped_token_service: true" as optional
16:28:28 <ayoung> I can do that
16:28:40 <kmalloc> this isn't config, this is system management
16:28:44 <ayoung> I wonder....
16:28:46 <kmalloc> so it should be something done in the api
16:28:54 <ayoung> so, I had a spec for "subcatalogs by id"
16:29:02 <ayoung> could "unscoped" be an id
16:29:20 <ayoung> and we define that as the identity services?
16:29:39 <kmalloc> you could just use the current API
16:29:53 <ayoung> https://review.openstack.org/#/c/160909/
16:29:53 <kmalloc> or you could add a new route, auth/catalog/unscoped
16:30:25 <kmalloc> you will need to inspect endpoints and any endpoints that have project/other subst in them will be omitted from the catalog
16:30:45 <kmalloc> but i think this is pretty straightforward
16:31:15 <kmalloc> and we can start with the default (aka bootstrap) populating the unscoped flag for keystone
16:31:36 <ayoung> OK  I think I got it.  I might add that approach to the spec
16:32:10 <ayoung> we can discuss it there, as I think it will be a big enough change that will merit API level review
16:32:22 <lbragstad> ++
16:32:28 <lbragstad> anything else on your specs ayoung ?
16:32:30 <kmalloc> ++
16:32:52 <ayoung> lets move my policy stuff to the end
16:32:56 <lbragstad> ok
16:33:27 <lbragstad> #topic federated auto-provision improvements
16:33:31 <kmalloc> yay!
16:33:33 <ayoung> when is the edge call?
16:33:43 <ayoung> I'll get it on my calendar
16:33:45 <kmalloc> iirc 7am pacfic, so... 1400 utc?
16:33:52 <lbragstad> so - james penick (from oath) has clearance to open-source their federated auto-provisioning stuff
16:33:55 <kmalloc> 10am eastern
16:34:10 <kmalloc> i *think*
16:34:11 <lbragstad> we were talking about it today on the edge call
16:34:22 <kmalloc> woot.
16:34:24 <lbragstad> #link https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings
16:34:25 <kmalloc> that makes me happy
16:34:29 <ayoung> yeah, 10
16:34:32 <lbragstad> yeah - no kidding
16:34:42 <kmalloc> oath's approach is the correct direction to push
16:34:51 <lbragstad> so - he asked if it would be ok if he wrote a spec highlighting the gaps between our implementation and theirs
16:34:53 <kmalloc> this makes it much easier.
16:35:02 <kmalloc> i would like that very much
16:35:15 <kmalloc> we can evaluate from there how far we can push to that implementation without breaking API contracts
16:35:21 <kmalloc> and what would need massaging
16:35:30 <lbragstad> i think he wants some help with it and said that he can try and get something proposed this week
16:35:43 <kmalloc> the spec is key, and as much detail as he can provide
16:35:50 <ayoung> Probably worth making sure we are in sync going in to the summit, too
16:35:50 <kmalloc> some of us can chip in for the code
16:35:56 <lbragstad> but he was concerned that some of it would be "wrong"
16:36:09 <lbragstad> or that we might reject parts of it
16:36:28 <kmalloc> the only real rejection i would see is if it breaks API contracts
16:36:35 <kmalloc> and we'd need to work around that in either case.
16:36:49 <lbragstad> yeah - i'd just be curious to see the implementation and figure out the gaps, then go from there
16:37:07 <kmalloc> based upon the edge work (and discussions), I can say I already err to the side of oath is doing it correctly
16:37:26 <kmalloc> it is a question of how do we make it work without breaking anyone else [might be extended/new apis] in upstream
16:37:29 <lbragstad> but - next week we're going to spend more time on it after james open-sources the code and proposes the specification
16:37:39 <lbragstad> and that will happen during the edge call
16:37:42 <kmalloc> cool.
16:37:49 <kmalloc> i shall try to be there.
16:37:54 <lbragstad> good deal
16:37:59 <lbragstad> that's all i had for that topic
16:38:00 <kmalloc> but 7am is rough because dogs/moring being started
16:38:03 <lbragstad> any questions?
16:38:05 <ayoung> I have the time blocked out.  I'll also make sure the web meeting tool works
16:38:15 <kmalloc> this is zoom, yes?
16:38:18 <ayoung> yeah
16:38:18 <lbragstad> correct
16:38:26 <kmalloc> i think they finally have a web-only version
16:38:28 <kmalloc> which works for me
16:38:36 <kmalloc> vs segfaulting my browser
16:38:41 <ayoung> Heh
16:38:44 <ayoung> OK...policy?
16:38:50 <lbragstad> yessir
16:39:04 <lbragstad> #topic updated policy project
16:39:10 <kmalloc> my policy is i dislike policy
16:39:11 <kmalloc> >.>
16:39:12 <kmalloc> <.<
16:39:17 * kmalloc couldn't resist
16:39:18 <ayoung> Last week, we had a big internal RH conference, and I met a couple people that are doing custom policy for some of our customers
16:39:33 <ayoung> specifically in search of a read only role.  THey had it in an internal git repo.
16:39:53 <ayoung> So...I had long had and idea like this on my todo list, but they actually did it.
16:40:04 <ayoung> I want to make this project "short term official"
16:40:15 <ayoung> meaning, eventually all the changes should make their way back to the proejcts
16:40:38 <ayoung> but in the meanwhile, we should have a unified set of policy files that people can use to enforce best practices
16:40:49 <lbragstad> does this conflict with the default roles work or system scope/
16:40:57 <ayoung> I think it complements it
16:41:01 <lbragstad> or is it a bandaid until that problem is fully fixed?
16:41:19 <ayoung> lbragstad, bigger than a band aid.  More like an iron lung
16:41:31 <ayoung> Lets call it a cast and crutches?
16:41:43 <lbragstad> ok
16:42:19 <ayoung> I want to get a set of policies that we can use with TripleO, but...I think this group understands policy better
16:42:43 <ayoung> here is what I have so far:
16:42:53 <ayoung> #link https://pagure.io/openstack-access-policy/tree/common-rules
16:43:02 <ayoung> the master branch is what they have for osp13
16:43:30 <ayoung> I took that and put a mini build system that lets us manage common rules, and built the policy.yaml files with the common sections pre-pended
16:43:38 <ayoung> It needs tests, like, desperately
16:44:21 <ayoung> once I can confirm that we can change the structure of the tests, but still keep things functioning, I want to start working toward mitigation for but 968696
16:44:29 <ayoung> that means first is_admin_project support
16:44:36 <ayoung> and then service scoping
16:44:58 <kmalloc> so, i have a single concern
16:45:02 <lbragstad> so - i'm already working on tests for system-scope and project-scope support
16:45:13 <ayoung> I don't think we have service scoping in OSP 13.  If we do, I'll skip is_admin_project
16:45:20 <kmalloc> i dislike "official" projects that are just in place to be deconstructed and deleted long term
16:45:28 <kmalloc> it's ... not a huge concern
16:45:40 <ayoung> lbragstad, so, my idea here for tests is to use the oslopolicy-checker and a score card
16:45:43 <kmalloc> just a "I don't like the hoops to just puill it apart"
16:45:54 <hrybacki> I will confirm that casts have their place
16:46:02 <ayoung> kmalloc, I hear you, but I also have no longer the will to try and get changes into every project out there
16:46:15 <ayoung> this needs to happen in a much faster time line
16:46:18 <kmalloc> and i am not saying i object to this project at all
16:46:29 <ayoung> it will be an official project.  Just..not sure who will hold the office
16:46:30 <kmalloc> just voicing the general "this feels icky" concern.
16:46:46 <ayoung> I can see there being a long term project for the common rules
16:46:47 <kmalloc> which sometimes ick is needed to get from A to B
16:47:06 <kmalloc> (just detouring a->i->c->k->y->b) ;)
16:47:28 <ayoung> and, then the build system might be to pull the project specific rules from the projects to build the overall policy...or a common library that the projects pull in if we want them to have the definitiev rules in code
16:47:38 <ayoung> this gives us a place to work
16:48:11 <ayoung> actually, since we put the rules in code, we really should have a common python library for common rules
16:48:26 <lbragstad> that would be oslo-policy imo
16:48:30 <ayoung> not quite
16:48:35 <ayoung> oslo-policy is a rules engine
16:48:46 <ayoung> but , with the exception of the roles check, it is agnostic of content
16:48:58 <ayoung> this would be oslo-rbac or something like that
16:49:04 <kmalloc> this could be like the vendor data in sdk
16:49:11 <ayoung> yep
16:49:17 <kmalloc> something that could be extracted from policy eventually
16:49:28 <kmalloc> it might belong in olso-policy to start, for ease of deployment
16:49:31 <kmalloc> and access
16:49:39 <kmalloc> that way it's available to everyone to start
16:49:43 <ayoung> we should probably namespace the common rules, then
16:49:54 <ayoung> common:is_admin etc
16:50:20 <kmalloc> that is in line with the consistent policy names lbragstad has proposed
16:50:34 <kmalloc> and i support namespacing common rules in a similar/consistent way
16:50:38 <lbragstad> merged*
16:51:07 <ayoung> https://bugs.launchpad.net/oslo.policy/+bug/1797739
16:51:07 <openstack> Launchpad bug 1797739 in oslo.policy "checker CLI does not enumerate all rules for glance" [Undecided,In progress] - Assigned to Adam Young (ayoung)
16:51:14 <ayoung> that is what happens without namespacing
16:51:15 <lbragstad> #link https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies
16:51:37 <lbragstad> ayoung glance doesn't have policy in code
16:51:43 <ayoung> thay also don'
16:51:56 <ayoung> they also don't have namespacing of their rules.
16:52:25 <lbragstad> #link https://review.openstack.org/#/c/501360/ needs to get picked back up
16:52:25 <kmalloc> tl;dr: namespace is consistent with the new "policy" for naming-policies. common rules should also be namespaced
16:52:57 <ayoung> so...I don't think this set of policy files/build belongs in oslo.policy, but I am willing to post it there if I get support for it from the rest of the team
16:53:15 <kmalloc> my only reasoning is for initial accessibility to the data
16:53:44 <kmalloc> if we are adding yet-another-thing, it is something that has to be added everywhere
16:53:54 <kmalloc> just trying to make your life easier.
16:54:06 <kmalloc> but if you want the harder route, by all means, propose it as a new thing :)
16:54:06 <lbragstad> ^ that's why i suggested it being in oslo.policy :)
16:54:40 * kmalloc ^5's lbragstad ;)
16:54:40 <lbragstad> (five minutes remaining)
16:55:00 <ayoung> ok...let me rethink how to structure it, so it fits in.  I guess a subdir, parallel to oslo-policy named...examples?
16:55:22 <ayoung> It feels wrong to call them examples, as they are supposed to be more production than that
16:55:24 <lbragstad> is their main purpose to be referenced or consumed?
16:55:29 <ayoung> consumed
16:55:33 <lbragstad> +1
16:55:42 <ayoung> common?
16:55:47 <kmalloc> i have one quick last thing before end of meeting
16:55:47 <lbragstad> then i'd think it's a sub-dir in oslo
16:56:01 <ayoung> OK...I'll try to come up with a name
16:56:25 <lbragstad> but arguable within oslo.policy
16:56:28 <lbragstad> kmalloc go ahead?
16:56:32 <kmalloc> flask -> Final patches proposed. There are 3 more "change the code" and some moving data, and then a lot of deleting. Please review. it's all done except for merging the last ~10 patches
16:56:43 <ayoung> w00T!
16:56:54 <lbragstad> #topic open discussion
16:56:56 <kmalloc> the last one is -1800+ lines.
16:57:02 <kmalloc> yes it felt good.
16:57:13 <gagehugo> lol
16:57:28 <kmalloc> +240, -1829
16:57:32 <vishakha> lbragstad: since its a open discussion now. I have some queries regarding unified limits
16:57:42 <lbragstad> vishakha go ahead
16:57:53 <kmalloc> vishakha: 2min, if it doesn't sneak in we can discuss in -keystone right after
16:58:06 * lbragstad notes that it's super late in japan
16:58:13 <vishakha> lbragstad: I got your point for keeping -1 as min for limits
16:58:45 <vishakha> lbragstad: what can be the max value set for default or resorce limit
16:59:01 <lbragstad> i think that depends on the deployer
16:59:17 <lbragstad> they should be able to set that to whatever they want
16:59:32 <vishakha> lbragstad: if I tries to set limit for around 1000000000 it gives me 500 server error
16:59:33 <lbragstad> so i'm not sure we should implement an upper bound, if that's what you're asking
16:59:45 <vishakha> yes exactly
16:59:56 <kmalloc> the upper bound should be defined as what we expect the column length to be
17:00:07 <lbragstad> yeah - which would be an implementation detail of sql
17:00:09 <kmalloc> so if we specify a unit32, it is the upper limit
17:00:24 <kmalloc> so we specify the defined limit as what we use for storage in the initial impl
17:00:33 <lbragstad> we can gracefully handle that, but that's about the best we could do i think
17:00:48 <kmalloc> pick a number that is within the limit and mark it as upperlimit
17:00:55 <kmalloc> 500 error is not correct behavior imo
17:00:57 <vishakha> ok . So will raise a bug for it
17:00:59 <kmalloc> yeah
17:01:07 <lbragstad> vishakha anything else on limits?
17:01:18 <kmalloc> should be a bug and Bad Request/Validation error if it exceeds the limit
17:01:46 <vishakha> Yeah one last thing I can set anything for resource name also?
17:01:56 <lbragstad> yes
17:02:21 <vishakha> I mean when II tries to list limit for invalid resource name it dont give any error
17:02:25 <lbragstad> we don't implement a set of resource - those are open-ended for service developers and operators to define
17:02:30 <vishakha> It lists all the limits
17:02:39 <kmalloc> there is again a length max on that data
17:02:49 <kmalloc> but otherwise no special nameing requirements
17:03:16 <lbragstad> vishakha i believe that is a filtering bug with query parameters GET /v3/limits?resource_name=foobars
17:03:22 <lbragstad> returns all limits
17:03:30 <lbragstad> because the query parameter is ignored since it doesn't exist
17:04:01 <vishakha> ok got it. Thanks this much for now in unified limits
17:04:08 <kmalloc> and that is correct behavior in keystone.
17:04:13 <lbragstad> vishakha thanks for jumping in and helping out
17:04:15 <lbragstad> thanks for coming everyone, good discussions today
17:04:18 <lbragstad> #endmeeting