Earlier  
Posted Nick Remark
#openstack-nova - 2022-11-16
14:47:05 sahid :-)
14:47:22 sean-k-mooney we normally do this latter but its similar to do it there
16:14:27 opendevreview Rafael Weingartner proposed openstack/nova master: Nova to honor "cross_az_attach" during server(VM) migrations https://review.opendev.org/c/openstack/nova/+/864760
16:27:03 bauzas sean-k-mooney: I'm not opposed to the fact we don't hardly specific cpu governors in nova and we let the operator decide which ones they want https://review.opendev.org/c/openstack/nova-specs/+/861591/comments/6a5d4488_55cda4bd
16:27:17 bauzas sean-k-mooney: but I wonder how we could let the operators *specify* it
16:27:27 bauzas a ListOpt doesn't really help
16:27:51 bauzas as we would need to guess which governor is the powersaving one and which one is the best performant
16:28:41 bauzas sean-k-mooney: and I feel a DictOpt is too much painful to add
16:29:10 bauzas sean-k-mooney: see my concern ?
16:39:25 sean-k-mooney well i was thinking of having the first be the low power and second high
16:39:37 sean-k-mooney but you could just add 2 config options
16:39:43 sean-k-mooney for high and low
16:40:03 sean-k-mooney dictopts are supporte by oslo but we dont currently use them in nova
16:40:25 bauzas correct hence me reluctant
16:40:40 sean-k-mooney bauzas: its really just the active/high-power one that we really care about
16:40:59 sean-k-mooney powersave runs the cpu at the lowest frequency it can without turning off
16:41:10 sean-k-mooney performance is the opicite
16:41:31 sean-k-mooney in general you would not want to hardcode perfromace if your trying to manage power
16:41:58 sean-k-mooney so if the high power one was configurable that woudl be enough
16:42:15 sean-k-mooney if you want to keep it simple howwever why not add two config options
16:42:36 sean-k-mooney cpu_high_power_govoner and cpu_low_power_govoner
16:42:41 sean-k-mooney just simple stings
16:42:58 bauzas yup, that's what I write now
16:43:05 sean-k-mooney works for me
16:43:10 bauzas we could bikeshed on the namings
16:43:11 sean-k-mooney gibi: ^
16:43:52 opendevreview Sylvain Bauza proposed openstack/nova-specs master: Proposes cpu power managment in libvirt https://review.opendev.org/c/openstack/nova-specs/+/861591
16:43:59 bauzas there you go
17:10:27 opendevreview Sylvain Bauza proposed openstack/nova master: Deprecate mdev creation and hardfail on reboot when missing. https://review.opendev.org/c/openstack/nova/+/864418
17:10:28 opendevreview Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976
17:10:28 opendevreview Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673
17:25:46 opendevreview John Garbutt proposed openstack/nova master: Ironic nodes with instance reserved in placement https://review.opendev.org/c/openstack/nova/+/864773
17:28:23 johnthetubaguy gibi: I think I may have found an "interesting" way to close that ironic scheduler race with automatic clean, but it feels a bit wrong, its a follow on from that patch you reviewed yesterday: https://review.opendev.org/c/openstack/nova/+/864773
17:31:34 gibi johnthetubaguy: that is a clever one
17:32:21 johnthetubaguy it might be too clever, but it seems to work... funky right?
17:33:10 gibi I think we intentionally designed placement in a way that it allows reserving already allocated inventories
17:33:27 gibi but not allow allocating reserved ones
17:33:47 gibi so I think what you do is OK from placement perspective
17:36:22 gibi how likely that a big ironic deployment has no cleaning configured and the update_provider_tree periodic is set to a big value due to preformance reasons?
17:36:35 johnthetubaguy OK, neat. I remember some related discussions around increasing host reserved memory, and it sounded OK ish.
17:37:14 johnthetubaguy ... unsure, that is a very good question. Most large deployments I work on do automatic cleaning, but I know that far from representative
17:37:38 johnthetubaguy (I have to run I am afraid, I am told my dinner is going cold)
17:37:59 gibi johnthetubaguy: no worries. I will leave the feedback in the review
17:40:42 gibi have a nice dinner
17:45:53 sean-k-mooney o/ just saw the comment on ironic reivew
17:46:08 sean-k-mooney is the plan to proceed with https://review.opendev.org/c/openstack/nova/+/842478 anyway
17:46:17 sean-k-mooney if so i can review again tomorrow
17:47:44 sean-k-mooney i am mostly out of brain power today but i dont mind looking at it in the morning
17:48:41 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/864773 is the other one? to review with https://review.opendev.org/c/openstack/nova/+/842478
17:51:52 sean-k-mooney and yes if you are over allcoated you cannot make new allcoations
17:52:01 sean-k-mooney but i think you are right that you can modify the reserve value
17:53:04 sean-k-mooney like you can go form reservice 0 cpus to 10 and if that would over allocate that is fine it will be resolved when a vm is delete/moved
17:54:01 sean-k-mooney i have not looked at johnthetubaguy clever solution but form context i assume it invovles setting the reserved value to 1 for the custom resoucs inventory that represnt the baremetal hosts
18:03:08 opendevreview Rafael Weingartner proposed openstack/nova master: Nova to honor "cross_az_attach" during server(VM) migrations https://review.opendev.org/c/openstack/nova/+/864760
22:02:18 opendevreview Rafael Weingartner proposed openstack/nova master: Nova to honor "cross_az_attach" during server(VM) migrations https://review.opendev.org/c/openstack/nova/+/864760
23:41:22 opendevreview Younghwan Yoo proposed openstack/nova master: Update return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674
#openstack-nova - 2022-11-17
01:57:53 melwitt bauzas: this patch looks relevant to your interests https://review.opendev.org/c/openstack/nova/+/864674
05:59:57 opendevreview Jorhson Deng proposed openstack/nova master: Optimize the small pagesize in numa_fit_instance_to_host https://review.opendev.org/c/openstack/nova/+/864812
08:04:56 opendevreview Jorhson Deng proposed openstack/nova master: Optimize the small pagesize in numa_fit_instance_to_host https://review.opendev.org/c/openstack/nova/+/864812
08:42:46 opendevreview Jorhson Deng proposed openstack/nova master: Optimize the small pagesize in numa_fit_instance_to_host https://review.opendev.org/c/openstack/nova/+/864812
09:44:05 johnthetubaguy When you run functional tests on your dev box, and you get loads of errors due to no valid host, it probably means I am doing something stupid, has anyone else hit that at all please?
10:09:15 bauzas johnthetubaguy: which testcases ?
10:11:16 johnthetubaguy good question, mostly the ones that use placement
10:11:41 johnthetubaguy there are loads of them in the functional suite, one example is: nova.tests.functional.wsgi.test_services.TestServicesAPI.test_resize_revert_after_deleted_source_compute
10:11:54 johnthetubaguy pretty sure its my environment being broken, as so many fail
10:19:47 johnthetubaguy ah, so I think it was by default python3 being 3.8, oops!
10:20:08 johnthetubaguy curiously, unit tests are just fine, but functional tests, no so much
10:22:12 bauzas johnthetubaguy: sorry was on a meeting
10:22:28 johnthetubaguy no worries, the fix was simple enough in the end
10:22:34 bauzas johnthetubaguy: yesterday I ran some reshape function tests locally and I had no problem
10:22:48 johnthetubaguy yeah, its my bad default python version, thats all
10:22:56 bauzas johnthetubaguy: oh, so due to py38 ? strange if so
10:23:02 johnthetubaguy yeah
10:23:11 bauzas I guess you recreated your venv too ?
10:23:31 johnthetubaguy I suspect something had failed to start and I didn't notice that, all I noticed was lots of no valid host exceptions
10:23:43 johnthetubaguy so tox spotted it and did the re-create
10:23:56 bauzas and it worked then ?
10:24:13 johnthetubaguy in tox.ini the base python is python3 rather than python3.9 I guess, which caused my "fun"
10:24:18 johnthetubaguy yeah, its working fine now
10:24:21 bauzas I suspect some os-resource-classes or os-traits library update wasn't updated
10:24:35 bauzas hence placement failing and then the novalidhosts eventually
10:24:45 bauzas doing the tox -r updated the deps
10:24:47 johnthetubaguy ah... got you, very possible
10:25:10 johnthetubaguy actually, I remember seeing some os-traits error actually
10:25:20 bauzas yeah, we hardfail on the number of traits
10:25:40 johnthetubaguy it was a missing attribute error I think, which is basically the same thing
10:25:48 bauzas cool
10:25:58 johnthetubaguy well mystery solved, thank you!
10:26:07 bauzas np, glad you fixed it by yourself :D
10:26:31 johnthetubaguy (makes bashing with a hammer noises)
10:27:06 bauzas :)
10:44:00 opendevreview John Garbutt proposed openstack/nova master: Functional test test_boot_reschedule_with_proper_pci_device_count https://review.opendev.org/c/openstack/nova/+/760354
10:44:01 opendevreview John Garbutt proposed openstack/nova master: Fix PCI passthrough race on reschedule (claims) https://review.opendev.org/c/openstack/nova/+/710847
10:44:01 opendevreview John Garbutt proposed openstack/nova master: Fix PCI passthrough race on reschedule (refresh) https://review.opendev.org/c/openstack/nova/+/710848
11:02:59 johnthetubaguy gibi: I think you reviewed those in the past, I am not sure it answers all your questions, but I put the functional test first, in an attempt to work out which patches are needed. Its a nasty bug that on re-schedule you try to get the wrong PCI device, but fail with in-use errors.
11:03:54 sean-k-mooney johnthetubaguy: so i was thinking about your ironic patch for reserving on schedule over night
11:04:04 sean-k-mooney i think in general its a good idea
11:04:32 sean-k-mooney there was some concern about if cleaning was used or not in large cloud right extendign the time they would be unavaiable
11:05:04 johnthetubaguy yeah, gibi was mentioning that, and well, I don't disagree
11:05:11 sean-k-mooney if we wanted to cater for that we coudl make this configurable but i think the its proably ok ot reserve by default or uncondtionally

Earlier   Later