Earlier  
Posted Nick Remark
#openstack-nova - 2023-08-31
21:02:50 opendevreview Merged openstack/nova master: Fix tox docs target https://review.opendev.org/c/openstack/nova/+/891033
21:48:44 sean-k-mooney melwitt: o/
21:49:43 melwitt sean-k-mooney: o/
21:50:48 sean-k-mooney so the way the doc and porting tool are managing vcpu quota is not correct
21:50:51 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/891646/5/nova/cmd/manage.py#3461
21:51:13 sean-k-mooney but i think we can adress both of those issues in a followup patch
21:51:45 sean-k-mooney when migrating the quota on flavor.vcpu it should not be mapped 1:1 to the vcpu resouce class limit exclively
21:51:58 sean-k-mooney we need to also set the same limit for PCPUs
21:52:30 sean-k-mooney since flavor.vcpu can be either VCPU alloctions , PCPU alloctions or both in the case of a vm with mixed cpus
21:52:55 sean-k-mooney so while that has the downside of effectivly doubling the qutoa for cpus
21:53:11 sean-k-mooney i think its the only way to avoid over quota issues in general
21:53:43 melwitt sean-k-mooney: hm, ok
21:54:06 sean-k-mooney since we have not made the new quota driver the default
21:54:10 sean-k-mooney just deprecated the old one
21:54:16 sean-k-mooney im fine with doing that in a followup
21:54:25 melwitt sean-k-mooney: you've reminded me there's a config option around this https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.unified_limits_count_pcpu_as_vcpu
21:54:33 melwitt as well
21:54:50 sean-k-mooney oh ya there is/was
21:54:56 melwitt ack. I'm working on follow up stuff
21:55:27 sean-k-mooney i have approved the two patches as they are since for most peopel it will do what they need
21:56:10 melwitt thank you
21:57:10 sean-k-mooney no worreis i came online to do that before i head to bed so ill chat to you soon o/
21:57:46 melwitt sean-k-mooney: thanks 🙏 ttyl o/
21:57:46 melwitt sean-k-mooney: thanks � ttyl o/
23:54:12 opendevreview Merged openstack/nova master: nova-manage: Add 'limits migrate_to_unified_limits' https://review.opendev.org/c/openstack/nova/+/891646
23:54:19 opendevreview Merged openstack/nova master: Add documentation for unified limits https://review.opendev.org/c/openstack/nova/+/893127
#openstack-nova - 2023-09-01
04:44:37 opendevreview OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/891648
04:56:39 opendevreview Merged openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Bobcat" https://review.opendev.org/c/openstack/nova/+/887255
06:01:31 opendevreview melanie witt proposed openstack/nova master: Follow up for unified limits documentation https://review.opendev.org/c/openstack/nova/+/893462
06:03:38 opendevreview melanie witt proposed openstack/nova master: Follow up for unified limits: PCPU and documentation https://review.opendev.org/c/openstack/nova/+/893462
06:04:39 melwitt johnthetubaguy, bauzas, sean-k-mooney: followup for unified limits to handle PCPU and add a bit more detail to docs ^ thanks
06:20:01 opendevreview melanie witt proposed openstack/nova master: Follow up for unified limits: PCPU and documentation https://review.opendev.org/c/openstack/nova/+/893462
06:33:57 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Refactor CinderFixture https://review.opendev.org/c/openstack/nova/+/893464
06:33:58 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Add function to get all attachments in Cinder.API module https://review.opendev.org/c/openstack/nova/+/893465
06:33:59 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Reproducer for dangling bdms https://review.opendev.org/c/openstack/nova/+/893466
06:35:30 opendevreview Amit Uniyal proposed openstack/nova stable/2023.1: Delete dangling bdms https://review.opendev.org/c/openstack/nova/+/893467
06:47:10 opendevreview Amit Uniyal proposed openstack/nova stable/zed: Adds regression functional test for 1980720 https://review.opendev.org/c/openstack/nova/+/893468
06:47:11 opendevreview Amit Uniyal proposed openstack/nova stable/zed: Refactor CinderFixture https://review.opendev.org/c/openstack/nova/+/893469
06:47:12 opendevreview Amit Uniyal proposed openstack/nova stable/zed: Add function to get all attachments in Cinder.API module https://review.opendev.org/c/openstack/nova/+/893470
06:47:13 opendevreview Amit Uniyal proposed openstack/nova stable/zed: Reproducer for dangling bdms https://review.opendev.org/c/openstack/nova/+/893471
06:47:14 opendevreview Amit Uniyal proposed openstack/nova stable/zed: Delete dangling bdms https://review.opendev.org/c/openstack/nova/+/893472
07:27:41 opendevreview Amit Uniyal proposed openstack/nova stable/yoga: Adds regression functional test for 1980720 https://review.opendev.org/c/openstack/nova/+/893474
07:27:42 opendevreview Amit Uniyal proposed openstack/nova stable/yoga: Refactor CinderFixture https://review.opendev.org/c/openstack/nova/+/893475
07:27:43 opendevreview Amit Uniyal proposed openstack/nova stable/yoga: Add function to get all attachments in Cinder.API module https://review.opendev.org/c/openstack/nova/+/893476
07:27:44 opendevreview Amit Uniyal proposed openstack/nova stable/yoga: Reproducer for dangling bdms https://review.opendev.org/c/openstack/nova/+/893477
07:27:45 opendevreview Amit Uniyal proposed openstack/nova stable/yoga: Delete dangling bdms https://review.opendev.org/c/openstack/nova/+/893478
07:40:52 bauzas morning folks
07:52:47 bauzas melwitt: on it
07:53:02 bauzas thanks for the quick follow-ups
07:53:47 bauzas auniyal: your series was tagged as a blueprint
07:54:17 bauzas auniyal: accordingly, you can't backport it in stable branches as it would change a behavior
07:57:25 bauzas see the backport policy rules that are given here https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
08:07:08 ykarel Hi is there some known issue with test_reboot_server_hard, recently saw many failures
08:07:45 ykarel Fails like AssertionError: time.struct_time(tm_year=2023, tm_mon=9, tm_mday=1, tm_hour=7, tm_min=26, tm_sec=24, tm_wday=4, tm_yday=244, tm_isdst=0) not greater than time.struct_time(tm_year=2023, tm_mon=9, tm_mday=1, tm_hour=7, tm_min=26, tm_sec=24, tm_wday=4, tm_yday=244, tm_isdst=0)
08:14:39 ykarel k didn't find a bug report, so reported https://bugs.launchpad.net/tempest/+bug/2033752
08:14:45 ykarel it's started just few hours back
08:41:58 bauzas ykarel: oh
08:42:08 bauzas probably related to some recent merge we did
08:42:47 bauzas because now we call Cinder when rebooting so the performance could be impactedcx
08:53:01 frickler elodilles: https://review.opendev.org/c/openstack/nova/+/871968 is still blocked by your W-1, can you please check?
08:54:29 frickler bauzas: calling cinder for a reboot? I'm curious about that, do you happen to have a reference?
08:55:08 frickler ah, https://review.opendev.org/c/openstack/nova/+/882284 ?
08:55:12 bauzas frickler: see the bug report
08:55:16 bauzas yea
08:56:44 elodilles frickler: looking, thanks
08:57:03 bauzas sean-k-mooney: dansmith: auniyal: looks like https://review.opendev.org/c/openstack/nova/+/882284 created a gate issue
08:57:04 frickler a reno referencing "this change" is weird wording btw
08:57:44 bauzas frickler: we can modify this
08:57:53 auniyal bauzas, ack
08:58:04 bauzas in general we say "Now, Nova does X or Y"
08:58:26 bauzas or "With this new feature named "blah", now we have"
09:02:15 bauzas auniyal: I'm working on a patch that will conditionnally check the volumes if only BDMs exist
09:02:51 auniyal ack bauzas, any thing I can help with
09:03:43 bauzas we may need core reviewers
09:04:36 frickler elodilles: thx, now just someone needs to retrigger the W+1 I think
09:09:03 elodilles frickler: i did it just before you wrote :)
09:10:09 bauzas auniyal: actually, we can't avoid a Cinder API call for getting the volumes
09:10:53 bauzas volume attachments*
09:11:02 auniyal yeah, I was about to say
09:11:11 auniyal saw the comment on bug report
09:11:56 auniyal cinder calls are separate from bdms what nova have
09:12:25 auniyal can we increase reboot time check ?
09:14:41 bauzas oh wait
09:15:09 bauzas this isn't calculating the time it boots
09:15:15 bauzas this is just getting the uptime
09:19:50 SvenKieske systemd-analyze time gives you boot times :)
09:20:04 SvenKieske without any context
09:23:38 bauzas that's weird then
09:24:04 bauzas https://github.com/openstack/tempest/blob/28ba6ee268bdf5d18a13a0dc7c7fea2c3a3dfcce/tempest/common/utils/linux/remote_client.py#L84-L88 is just giving me when the server was booted
09:24:56 bauzas and https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_server_actions.py#L127-L128 is just comparing the timestamps to check that the VM was actually rebooted
09:25:11 bauzas this isn't at all a performance check
09:30:55 SvenKieske I'm not understanding your last sentence: do you mean this isn't supposed to be a performance check, or are you indicating that this should be a performance check but fails to do so?
09:31:52 SvenKieske depending on what stage the virtual machine is in, the time comparison could be flaky, during early boot especially, if time is not correctly synced.
09:33:18 SvenKieske I'd also strongly advise not to directly get stuff from proc-fs. why not use a native python function instead at least?
09:33:21 bauzas SvenKieske: Tempest gets the uptime, subs it from the current time so it gets the local time when the server was booted, then reboots the server and does the same math with uptime
09:34:07 bauzas and then there is an assertion check that verifies that the reboot timestamp is greater than the original timestamp (meaning the OS was actually rebooted)
09:34:40 bauzas https://github.com/openstack/tempest/blob/28ba6ee268bdf5d18a13a0dc7c7fea2c3a3dfcce/tempest/api/compute/servers/test_server_actions.py#L127-L128 and https://github.com/openstack/tempest/blob/28ba6ee268bdf5d18a13a0dc7c7fea2c3a3dfcce/tempest/api/compute/servers/test_server_actions.py#L109
09:34:53 SvenKieske I hope that test never runs during dailight saving time adjustments *just kidding*
09:35:16 bauzas UTC exists for a good reason :)
09:35:52 bauzas basically, this failing check means that the server *wasn't* rebooted

Earlier   Later