Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-05
15:10:24 mnaser :P
15:10:57 efried I think I have a pretty major rework to do on this patch now that I'm thinking in terms of the inventory refreshes...
15:11:05 mriedem tssurya: https://bugs.launchpad.net/nova/+bug/1793569
15:11:06 openstack Launchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,Confirmed]
15:11:31 tssurya mriedem: thanks
15:12:30 mnaser http://paste.openstack.org/show/734146/
15:12:35 mnaser easier to digest paste because of launchpad's wrapping
15:12:44 mnaser tssurya: ^
15:13:07 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.openstack.org/602201
15:18:21 tssurya mnaser: thanks :)
15:18:39 mriedem efried: fwiw, i would at least split out the change to disable the refresh interval (config value of 0)
15:18:47 mriedem since that's pretty straight forward i imagine
15:18:54 efried mriedem: ack, thx
15:50:48 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167
15:50:48 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Force refresh instance info_cache during heal https://review.openstack.org/591607
15:55:39 openstackgerrit Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167
16:11:26 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Trust the report client cache more https://review.openstack.org/614886
16:33:03 efried stephenfin: Does :oslo.config:option: not work in renos yet?
16:33:55 stephenfin efried: https://github.com/openstack/nova/blob/master/doc/source/conf.py vs. https://github.com/openstack/nova/blob/master/releasenotes/source/conf.py
16:34:11 stephenfin efried: It's a different build. You'd need to configure it for reno
16:34:22 stephenfin But I strongly advise against doing so
16:34:31 efried stephenfin: ack. I think I don't care that much.
16:34:36 efried why would you advise against it?
16:34:49 stephenfin If we removed/renamed the option in the future, we'd break the build
16:35:05 efried as we should
16:35:07 efried oh
16:35:15 efried the reno should be able to stay forever
16:35:17 efried got it.
16:35:20 stephenfin Yup
16:35:28 efried butbutbut
16:35:37 sean-k-mooney i was about to say we cant fix rennos after teh fact right
16:35:50 efried shouldn't it therefore point to the respective version of the config.html?
16:35:57 sean-k-mooney or at least its non trivail to change them after a release is done
16:36:33 efried sean-k-mooney: You asked me to review https://review.openstack.org/#/c/610034/ -- I'm out of my depth on that one, I'm afraid.
16:36:36 sean-k-mooney efried: it would if you had the commit checked out
16:36:37 stephenfin sean-k-mooney: We couldn't in the past but we can now (reno fixed that). That said, why make life hard for yourself
16:36:42 stephenfin *?
16:36:56 stephenfin efried: I guess it should, yes
16:36:57 sean-k-mooney efried: ok no worries
16:37:12 stephenfin But that ship has long since sailed. All our doc links in renos point to latest
16:37:39 efried sean-k-mooney: You spelled "outer" wrong! -2!
16:38:01 efried that's about the best I can do on that one.
16:38:04 sean-k-mooney where in the patch
16:38:18 efried https://review.openstack.org/#/c/610034/10/nova/utils.py@1322
16:38:48 sean-k-mooney ...
16:39:23 sean-k-mooney yes i did ...
16:40:26 sean-k-mooney that means its incorrect in the placement version too which is a pain.
16:40:50 sean-k-mooney ill repin hopefully for the last time
16:41:22 sean-k-mooney efried: thanks for finding it it woudl have been even more of a pain when backporting this
16:42:05 efried sean-k-mooney: Well, it's really not a big deal, especially since that method isn't exposed anywhere outside of the decorator. But sure, if you're going to respin; I imagine the other non-blocking nits are worse than that :)
16:42:39 sean-k-mooney well i wasnt but i can if needed
16:43:20 sean-k-mooney this has been part of an a downstream ci blocking bug for almost a month so i would like to finally get it fixed
16:48:05 openstackgerrit Lance Bragstad proposed openstack/nova master: WIP: experiment with oslo.limit interface https://review.openstack.org/615602
16:48:38 lbragstad johnthetubaguy i took a wild crack at bringing the oslo.limit logic closer to the actual enforcement point, based on the commit you have ^
16:49:07 johnthetubaguy lbragstad: ah, interesting, will have a look
16:49:38 lbragstad i guess i wanted to try and see if it was possible to make oslo.limit simple enough to not require a nova.limit module for dynamic limits
16:49:48 lbragstad but - what you have there for static limits totally makes sense
16:50:28 lbragstad i was just thinking that the original direction of the context manager might be hard to take advantage of if we go from api code -> limit module -> oslo limit
16:50:57 lbragstad since oslo.limit and the Enforcer context manager was written to be as close to the actual code consuming resources as possible
16:51:20 johnthetubaguy the problem is the retry check is always in another process at the moment
16:51:44 johnthetubaguy so not sure where the context manager will help, I am hoping jaypipes's patch will be different though
16:52:35 lbragstad dumb question, but what do you mean by the retry logic being in a different process?
16:52:58 lbragstad i was under the assumption that retry logic was in the same area of code that the resource consumption happens
16:53:00 sean-k-mooney what are people feeilngs about adding more debug logs in the schduler
16:53:15 sean-k-mooney or rather in the numa_toplogy_filter to be specific
16:54:06 sean-k-mooney im trying to debug a no valid host form schduler logs and the is nothing to go on to determin why the numa toplogy filter decied it was invlaid
16:54:18 johnthetubaguy lbragstad: it isn't at the moment sadly
16:54:55 lbragstad is the retry logic the thing that protects against race conditions between clients/
16:55:00 lbragstad or is that something else?
16:55:06 jaypipes sean-k-mooney: if a deployer is using the NUMATopologyFilter, they don't care about quickness of the scheduler. I say go for it.
16:55:39 johnthetubaguy sean-k-mooney: I prefer debug logs only on the reject path, if possible, but what jaypipes said too
16:55:58 johnthetubaguy lbragstad: it is that thing, let me link to an example
16:56:17 sean-k-mooney ya it wanted to pring the host toplogy and requested guest topology as a debug message only on failure
16:56:31 johnthetubaguy lbragstad: this is the recheck for build requests: https://review.openstack.org/#/c/615180/5/nova/conductor/manager.py
16:57:08 sean-k-mooney at the moment we jsut asy it did not fit
16:57:23 sean-k-mooney that could be a little noisy however...
16:57:30 johnthetubaguy lbragstad: the first check is in the API process, here: https://github.com/openstack/nova/blob/8d089111c8554e94e117ada3a7f51a42df59e84f/nova/compute/api.py#L868
16:57:36 lbragstad ahhh
16:57:45 johnthetubaguy lbragstad: the recheck is in the conductor, after calling the scheduler
16:57:46 lbragstad interesting... so that's not API code
16:57:57 lbragstad i see what you mean
16:58:05 melwitt sean-k-mooney, tssurya: looks like this already got explained but I can also pile on and say that per user quotas are per project only. so the two-level hierarchy in unifed limits in keystone gets you the same functionality from a nested quota standpoint
16:58:41 sean-k-mooney melwitt: ya that was news to me that user quotas are per project
16:58:52 melwitt gotcha
16:59:04 johnthetubaguy lbragstad: sadly the simplest examples of the recheck basically don't get moved to unified limits
16:59:20 lbragstad because it's not in nova-api?
17:00:04 johnthetubaguy lbragstad: well this is one that could move to unified limits with a context manager, but it doesn't really make sense for other reasons: https://review.openstack.org/#/c/615180/5/nova/api/openstack/compute/server_groups.py
17:00:27 stephenfin jaypipes: Out of curiosity, did you ever post your slides for "Scheduler Wars: A New Hope" anywhere?
17:00:31 lbragstad because it's not really a consumable resource, right?
17:00:41 johnthetubaguy lbragstad: yeah
17:00:47 lbragstad limiting server groups is more of a rate limiting thing
17:00:59 johnthetubaguy yeah, its a db bloat protection
17:01:07 lbragstad got it
17:02:10 openstackgerrit Eric Fried proposed openstack/nova master: Allow resource_provider_association_refresh=0 https://review.openstack.org/615606
17:02:15 johnthetubaguy lbragstad: just to confuse things, I actually propose we remove the rechecks for these rate-limit like things in the spec, since the check is being demoted lets tidy the code up a bit more if we can
17:02:56 lbragstad based on my super vague understand of all this, that seems reasonable
17:02:57 johnthetubaguy lbragstad: I am planning on keeping the recheck for everything in unified limits, but right now one part is in API the other is in the conductor process
17:03:09 melwitt johnthetubaguy: is the conductor recheck the only problem area for the oslo.limit verify? because I've had a TODO in my head to move the recheck back to nova-api
17:03:22 lbragstad oh, nice...
17:04:55 johnthetubaguy melwitt: not sure its too much of a problem really, but that is the only recheck that is relevant in the end. Isn't the issue that we need to write into the correct DB before we recheck?

Earlier   Later