Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-10
13:00:02 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793
13:00:02 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693
13:00:03 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'InstanceNUMATopology.cpu_pinning' property https://review.opendev.org/680106
13:00:03 openstackgerrit Stephen Finucane proposed openstack/nova master: Validate CPU config options against running instances https://review.opendev.org/680107
13:00:04 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Use sane indent https://review.opendev.org/680229
13:00:04 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field https://review.opendev.org/680108
13:00:05 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800
13:00:05 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571
13:00:06 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801
13:00:06 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Make 'Connection.getHostname' unique https://review.opendev.org/681060
13:00:07 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Mock 'libvirt_utils.file_open' properly https://review.opendev.org/681061
13:00:07 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895
13:04:55 stephenfin bauzas, alex_xu: I've merged in those follow-ups to https://review.opendev.org/#/c/671793/ and the next two patches, per dansmith's request, if you fancy re +2ing
13:05:18 bauzas ack
13:07:05 gibi bauzas: replied in https://review.opendev.org/#/c/676140
13:07:13 bauzas gibi: cool thanks
13:07:59 luyao efried: Hi efried, are you around?
13:08:13 mriedem gibi: do you have a bug reported for https://954d3ddb67e757934983-a9cc155153d08dd30dfffbbf1d71d234.ssl.cf5.rackcdn.com/676138/16/gate/nova-tox-functional-py36/fb5d235/testr_results.html.gz yet?
13:08:47 gibi mriedem: not yet. I have a patch that shrinks the window
13:08:58 gibi https://review.opendev.org/#/c/681238/
13:09:28 efried luyao: o/
13:10:09 bauzas gibi: mriedem: just an unrelated thought, should we somehow persist VGPU resource request to the RequestSpec requested_resources field ?
13:10:33 luyao efried: I would like another patch to refactor this later if necessary. Current appproach works well and it will be great for me to change after merged. https://review.opendev.org/#/c/678452/22/nova/compute/resource_tracker.py@1168
13:10:34 gibi requested_resources field is intentionally not persistes in the db
13:10:40 gibi bauzas: ^^
13:11:00 bauzas k
13:11:01 efried bauzas: imo VGPU should take its lead from what's been done with vpmem
13:11:20 efried move vgpu into the resources field
13:11:26 bauzas for the moment, we don't really do anything, we just take the allocation that was done
13:11:29 stephenfin dansmith: When you're around, we're going to need to discuss https://review.opendev.org/#/c/671801/40/nova/conf/scheduler.py@208 so I can grasp where you're coming from
13:11:58 bauzas efried: WDYM ? sorry, don't have a lot of contect of VPMEM apart of the spec
13:12:45 efried luyao: Yes, I completely overlooked the fact that the report client's provider tree doesn't have the resources in it. I agree we should keep it this way for now, but I think for the refactor we may want to reduce the data structure stored in the RT to just a dict, keyed by rp_uuid, of lists of resources.
13:13:04 efried bauzas: Unless you were thinking to do this for Train, let's talk about it after FF.
13:13:35 bauzas efried: of course not, just considering the next steps
13:13:42 efried stephenfin: Are you going to have time today to review the vpmem series?
13:13:47 luyao efried: Okey, we can discuss the details in the future. :)
13:13:49 bauzas since we plan to do VGPU affinity
13:14:44 stephenfin efried: I am, and I'm going to hold off on the follow-up requested for https://review.opendev.org/#/c/674895/ because reviews seem more important at the moment, right?
13:14:45 efried brinzhang: looks like you already got your novaclient release merging, yah?
13:15:10 efried stephenfin: totally
13:16:36 openstackgerrit Merged openstack/nova master: Indent fake libvirt host capabilities fixtures more nicely https://review.opendev.org/679339
13:16:37 gibi mriedem: field a bug https://bugs.launchpad.net/nova/+bug/1843433
13:16:37 openstack Launchpad bug 1843433 in OpenStack Compute (nova) "functional test test_migrate_server_with_qos_port fails intermittently due to race condition" [Undecided,New]
13:17:22 bauzas gibi: you could triage it as critical since it impacts the gate IMHO
13:17:35 bauzas gibi: any ideas of the failure rate?
13:17:37 gibi bauzas: does it block the gate?
13:17:48 mriedem http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22in%20test_migrate_server_with_qos_port%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d
13:17:51 mriedem it's not critical
13:17:55 mriedem yes it hits the gate but doesn't block it
13:18:04 bauzas mriedem: okay, thanks, I was about to ask logstash
13:18:05 mriedem gibi: ack, i left a few comments in the patch to close the race
13:18:16 gibi mriedem: thanks. I will respin soon
13:18:21 bauzas gibi: what's the patch up for this ?
13:18:34 gibi bauzas: https://review.opendev.org/#/c/681238/1
13:19:00 bauzas gibi: tbh, I'm a bit afraid it's at the top of the series
13:19:16 bauzas if you need to respin, I'd appreciate you move it down
13:19:25 luyao efried: Could you help confirm will an rebuild instance have two groups of allocations? I knew migration instance will change one allocation consumer to migration uuid. https://review.opendev.org/#/c/678452/23/nova/compute/resource_tracker.py@406
13:19:25 gibi bauzas: I think it is top of master
13:19:32 bauzas yup
13:19:49 gibi bauzas: so it is not connected to the series
13:19:57 gibi bauzas: just by topic
13:20:08 mriedem right, it's a race in an already merged functional test,
13:20:13 mriedem so let's just fix the race and merge it
13:20:21 bauzas gibi: my bad, you're right
13:20:26 gibi mriedem: good suggestion about instance event, that will fix the race
13:20:33 mriedem \o/
13:20:56 gibi I was affraid we need to poll the migration allocation in placement to close the race
13:21:19 gibi mriedem: I also fixed the bug grenade found in revert
13:21:40 gibi mriedem: unfortunately we still not have test run on that patch
13:21:53 aspiers kashyap: oh, I thought you were talking about cpuid inside the guest
13:22:09 mriedem gibi: yeah i saw you updated but i haven't looked at your replies or changes,
13:22:13 aspiers kashyap: I think there are multiple binaries with SB
13:22:17 mriedem it kind of sucks that we don't store the information needed for revert in the migration context
13:22:41 gibi mriedem: I have better plans, described in my reply
13:22:56 gibi mriedem: we can let neutron remember the mapping
13:23:09 kashyap aspiers: Sorry, I was not clear. I don't _know_ if it is also reported in the guest `cpuid` -- maybe you can tell from your hardware?
13:23:10 gibi mriedem: by using multiple portbinding
13:23:27 aspiers kashyap: I don't have a guest with cpuid installed currently
13:23:46 aspiers kashyap: I think I misremembered - before I probably ran it on the host
13:24:19 kashyap aspiers: For SB -- IMHO, you don't _need_ all those 4M, 2M variants -- it's beyond overkill. Your life, and admins life will be far more simpler, if you used the "two pairs" approach I noted in the comment
13:24:43 aspiers kashyap: You're preaching to the choir. You really need to file a bug report on bugzilla.opensuse.org
13:24:47 mriedem gibi: ah yeah
13:24:53 sean-k-mooney artom: i have confirmed that the migration context correctly contains the new numa toplogy blob but it does not get saved to the db
13:25:02 aspiers kashyap: or reach the right team in some other way
13:25:07 kashyap aspiers: Aaah, sorry; didn't realize we're on the same line, same word
13:25:23 openstackgerrit Adam Spiers proposed openstack/nova master: Improve SEV documentation and other minor tweaks https://review.opendev.org/681254
13:25:50 aspiers efried, gibi, stephenfin: there's the follow-up ^^^
13:25:58 sean-k-mooney artom: so do ing apply migration context followed by drop to delete it form the db does not work
13:26:23 sean-k-mooney artom: i would assume that for some reason the filed is not flaged as dirty and is not being saved
13:26:37 gibi aspiers: ack!
13:27:59 Sundar Hi sean-k-mooney, how are you doing?
13:28:07 sean-k-mooney Sundar: hi
13:28:11 efried luyao: I'm trying to make sense of those scenarios right now.
13:28:34 Sundar sean-k-mooney: The Cyborg patches for nova-integ have merged; https://review.opendev.org/#/q/project:openstack/cyborg+branch:master+topic:nova-integ+owner:Sundar
13:28:58 sean-k-mooney Sundar: ok so its just the nova code that is pending
13:29:07 Sundar There is one related patch for Nova notification https://review.opendev.org/674520 that is close
13:29:24 aspiers kashyap: Where did you hear that an SEV-enabled kernel would fail to boot if SEV is not provided? I have empirically proven that false by booting the same image both with and without SEV
13:29:58 sean-k-mooney Sundar: ok yes without that nova will timeout waiting and rollback the spawn
13:30:16 mriedem Sundar: no testing at all for those cyborg patches?
13:30:18 Sundar Yes. BTW, I updated the Nova patches too. Notification works with 674520. If you look at the seeming UT failures, they are mostly unrelated to Cyborg

Earlier   Later