Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-05
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: Force refresh instance info_cache during heal https://review.openstack.org/591607
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: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?
17:06:05 lbragstad for historical context, what was the reason for moving the recheck logic to conductor? Just to have it closer to the database?
17:06:06 melwitt johnthetubaguy: it is, but related to behavior change we have where multi-create causes potentially a lot of instances to fall into ERROR state if recheck fails, I had been thinking we should instead count build requests + instances for the recheck and do that in nova-api instead of doing the conductor thing
17:06:27 melwitt lbragstad: because that's where the instance record is created, yes
17:06:33 lbragstad got it
17:07:16 johnthetubaguy lbragstad: would it not be OK just to make the context manager optional, because when verify=false the context manager is really strange?
17:07:28 melwitt I can propose a WIP patch today to show what I mean. I just hadn't gotten around to trying it out
17:07:29 johnthetubaguy melwitt: oh good thinking... build requests

Earlier   Later