Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
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
06:48:14 alex_xu stephenfin: sorry, just send at wrong channel, the sample files are deleted by this commit https://review.openstack.org/#/c/149129/, and actually, the api sample test doesn't validate the request body, so there is no complain, those file actually just for document.
06:52:29 gmann alex_xu: stephenfin this will fix - https://review.openstack.org/#/c/588420/4
06:53:27 alex_xu gmann: thanks
06:54:07 alex_xu gmann: but I'm thinking about why we cleanup those empty file at https://review.openstack.org/#/c/149129/
06:55:36 gmann alex_xu: not sure why we removed may be because their are just empty
06:55:52 gmann they are just empty
06:56:25 alex_xu gmann: yea, anyway, your fix is better
07:00:16 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Remove unused request API sample template https://review.openstack.org/588420
07:00:38 gmann alex_xu: done ^^
07:02:54 alex_xu gmann: thanks
07:23:36 openstackgerrit Yongli He proposed openstack/nova master: Load expected attr pci_devices while migrate https://review.openstack.org/588455
07:31:32 openstackgerrit Merged openstack/nova master: Add another up-call to the cells v2 caveats list https://review.openstack.org/581910
08:22:13 giblet stephenfin: you found it you can make sure it is fixed ;) https://review.openstack.org/#/c/588420/

Earlier   Later