Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
21:56:30 sean-k-mooney by the way looking at http://ci-watch.tintri.com/project?project=nova&time=7+days i do not see teh intel nfv ci. https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI has not been updated since febuary. anyone rememebr the last time they saw it comment on something?
21:56:35 openstackgerrit Merged openstack/os-vif stable/queens: fix tox py27 job https://review.openstack.org/567942
21:57:26 melwitt sean-k-mooney: can't remember. it's been awhile
21:58:35 sean-k-mooney i have been waiting for it to comment on some change i was doing to networking-ovs-dpdk... i guess ill jsut do the testing myself.
21:59:07 tonyb sean-k-mooney: If you really cared to find out you could add the notes ref to you nova repo and then grep the notes for a comment from that CI
21:59:15 tonyb it *might* work
22:00:03 sean-k-mooney tonyb: oh? im not sure i follow
22:00:45 tonyb sean-k-mooney: gimme 5 to find a link
22:00:51 sean-k-mooney as in a gerrit query for a reviewer?
22:01:18 tonyb sean-k-mooney: Oh you could do that as well
22:01:47 melwitt oh yeah, good idea
22:02:11 tonyb sean-k-mooney: So looking at https://git.openstack.org/cgit/openstack/nova/commit/?id=2499f616094f63ed0a1a3c201789d14cc61a62c4
22:02:43 tonyb 'notes' get added to each review based on code-reviews. they're in a seperate ref
22:03:09 tonyb so you can just add that ref to your nova repo and then when you do git show on a SHA you'll get to see the reviewers
22:03:25 tonyb so the CI votes (but not comments) would be included.
22:04:34 tonyb https://review.openstack.org/#/q/reviewedby%3Aintel-nfv-ci
22:04:46 tonyb look slike it's still voting
22:05:58 sean-k-mooney maybe what does exception meen next to a ci comment https://review.openstack.org/#/c/584829/
22:06:44 tonyb sean-k-mooney: Oh it means it's voting but not doign anythign helpful ;P
22:07:35 sean-k-mooney ah it makes perfect sense lol
22:07:56 tonyb ;p
22:08:17 tonyb sean-k-mooney: Let me see if I can find the last time it voted +1
22:10:26 tonyb sean-k-mooney: Nope my gerrit fu is weak right now. I'll grab some coffee and try again
22:11:12 sean-k-mooney well looking at the log server it has not uploaded anything sice the 18th http://52.27.155.124/portland/2018-07-18
22:13:48 sean-k-mooney tonyb: thanks for trying in anycase. i might reach out and ask what the status is.
22:20:34 openstackgerrit Takashi NATSUME proposed openstack/nova master: Reno for notification-transformation-rocky https://review.openstack.org/588403
22:35:28 melwitt lbragstad: sorry for the delayed reply, but yeah what I was thinking was to look at migrating to keystone limits in stein, not yet going for the enforce part. johnthetubaguy had also mentioned that a two-stage approach to the migration might make migration easier from an operator perspective but I didn't understand that bit
22:38:43 melwitt side is the enforce with what we already have. then next stage will be to move to oslo.limit for enforcement
22:38:43 melwitt we have other work we'd like to do like be able to set quota limits for custom resource classes and where we're at right now, we could do that via our existing quota classes API, but then that will leave more to have to migrate to keystone limits when we move. so I was thinking maybe we should move to keystone limits first, then let the limits piece of custom resource class quotas be covered by unified limits, and all we do on our
22:43:20 lbragstad interesting melwitt
22:43:46 lbragstad so - you'd query keystone directly for limit information as opposed to using oslo.limit?
22:44:24 melwitt yeah. I actually didn't know the limit query was supposed to go through oslo.limit. if it does, we could do that, I just missed it or forgot
22:44:56 melwitt or are you saying limit + enforce are coupled?
22:45:01 melwitt in oslo.limit
22:45:04 lbragstad technically - it probably doesn't _have_ to go through oslo.limit, but that's where we were going to hide all the logic that understands the project tree
22:45:12 melwitt right okay
22:45:18 tonyb sean-k-mooney: Ahh when it votes it doens't actually 'vote' it just leaves a comment so it's back to groveling in the review metadata :(
22:45:44 lbragstad melwitt: i'm trying to map terms, but i was under the assumption that enforcement would be a requirement?
22:45:49 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927
22:45:50 openstackgerrit Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033
22:45:51 openstackgerrit Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598
22:45:52 openstackgerrit Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599
22:45:53 openstackgerrit Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648
22:45:54 openstackgerrit Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034
22:45:55 openstackgerrit Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049
22:45:56 openstackgerrit Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236
22:45:57 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Remove redundant _update()s https://review.openstack.org/588091
22:46:15 lbragstad if not - then it sounds like something we can build into oslo.limit or consider supporting (since it's the thing raise exceptions to the service)
22:46:26 melwitt lbragstad: it is, sorry. I mean whether it's one call or two calls in oslo.limit to do limits vs enforce
22:46:49 lbragstad oh - the thing that protects against race conditions?
22:47:21 melwitt sorry, I think I'm confusing things and I haven't looked at the POC code in awhile
22:47:46 lbragstad the skeleton of oslo.limit has that implemented in the context manager https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L60-L62
22:48:06 melwitt ah, yeah I remember now
22:48:13 lbragstad https://github.com/openstack/oslo.limit/blob/master/oslo_limit/tests/test_limit.py#L96 probably helps visualize things a bit, too
22:48:22 lbragstad from a usage perspective anyway
22:49:31 melwitt thanks
22:49:37 lbragstad this stuff will get implemented soon, since this is where the code the calculates the limits wrt the tree https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L81-L85
22:49:57 lbragstad (implementation detail of the context manager though)
22:49:58 melwitt and that will also pull the limits from keystone?
22:50:07 lbragstad yep - exactly
22:50:32 lbragstad when you enter the context manager, it should query keystone for the limits and do calculations based on the claims your making
22:50:51 melwitt ah, I see. I think I jumped the gun then. for some reason I was thinking we could move to using keystone limits only, as a first step, and then start doing the oslo.enforcement in a second separate step
22:50:52 lbragstad then __exit__ will do error handling in the event there was a race condition and verify = True
22:51:00 melwitt from a project perspective
22:51:05 lbragstad aha - sure
22:51:16 lbragstad hopefully it's only one step for you
22:51:29 lbragstad (unless there is a good reason to break things up a bit?)
22:51:44 melwitt no, I don't think there is. just ignorance on my part
22:51:55 lbragstad it's a lot of moving pieces =/
22:52:04 melwitt yeah, for sure
22:52:26 lbragstad we were waiting on an APi to return the project heirarchy with limit data associated to it (landed in rocky)
22:52:50 lbragstad now that's in, we can start working on finishing up the implementation of that context manager
22:52:59 lbragstad (i'm hoping to start that soon)
22:53:09 melwitt on our side we have to decide whether to go ahead with the custom resource classes quotas by using our own quota classes API or wait for oslo.limit
22:54:11 lbragstad i can bump the oslo.limit impl up on my priority list if it helps give you all a definitive direction
22:54:23 lbragstad (if support in oslo.limit is the question)
22:55:16 melwitt have to dig in more on what's the cost of that. might not be much actually because we can leverage our own old API for doing it. it's just then we'd have to migrate whatever quota classes people have created over to keystone limits. but we have to do that regardless so maybe it's not much extra cost
22:55:34 lbragstad sure
22:55:54 lbragstad i think i see what you mean
23:00:38 melwitt lbragstad: re: the comments on our PTG etherpad, there is already support for user_id right? as shown on this doc? https://docs.openstack.org/keystone/queens/admin/identity-unified-limits.html
23:02:38 melwitt we've had discussions with operators in the past and there was consensus that user_id isn't useful if hierarchy is possible, but I don't know if/how we could change the semantics of our existing quotas. so I'm thinking of what's possible if we *don't* change semantics
#openstack-nova - 2018-08-03
00:58:02 openstackgerrit melanie witt proposed openstack/nova stable/ocata: [stable only] Handle quota usage during create/delete races https://review.openstack.org/582413
00:58:04 openstack bug 1783613 in OpenStack Compute (nova) ocata "[ocata only] quota usage not decremented during boot/delete race" [Undecided,In progress] https://launchpad.net/bugs/1783613 - Assigned to melanie witt (melwitt)
00:58:04 openstackgerrit melanie witt proposed openstack/nova stable/ocata: Add functional regression test for bug 1783613 https://review.openstack.org/588416
00:58:08 openstackgerrit Merged openstack/nova master: In Python3.7 async is a keyword [1] https://review.openstack.org/584365
00:59:25 openstack bug 1783613 in OpenStack Compute (nova) ocata "[ocata only] quota usage not decremented during boot/delete race" [Undecided,In progress] https://launchpad.net/bugs/1783613 - Assigned to melanie witt (melwitt)
00:59:25 openstackgerrit melanie witt proposed openstack/nova stable/ocata: [stable only] Add functional regression test for bug 1783613 https://review.openstack.org/588416
00:59:26 openstackgerrit melanie witt proposed openstack/nova stable/ocata: [stable only] Handle quota usage during create/delete races https://review.openstack.org/582413
01:15:46 melwitt mriedem_afk: I added a functional regression test that might help demonstrate the bug ^
01:18:19 melwitt customer hit an issue around this so I proposed it upstream too in case it can help
01:30:38 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove unused request API sample template https://review.openstack.org/588420
01:31:45 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove unused request API sample template https://review.openstack.org/588420
01:34:52 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove unused request API sample template https://review.openstack.org/588420
01:44:07 lbragstad melwitt: oh - so don't try and support per user quotas?
01:51:53 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Update installation guide to be more clear about cellsv2 https://review.openstack.org/584244
01:56:47 openstackgerrit zhufl proposed openstack/nova master: Fix none-ascii char in doc https://review.openstack.org/588422
03:03:42 openstackgerrit Vishakha Agarwal proposed openstack/nova master: No change in field 'updated' in server https://review.openstack.org/586446
04:38:48 openstackgerrit melanie witt proposed openstack/nova stable/ocata: [stable only] Handle quota usage during create/delete races https://review.openstack.org/582413
05:57:32 openstackgerrit Vishakha Agarwal proposed openstack/nova master: 'Updated_at' is NULL when show aggregate info https://review.openstack.org/580271
06:06:56 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove unused request API sample template https://review.openstack.org/588420

Earlier   Later