| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-03 | |||
| 15:00:11 | sean-k-mooney | its one of the thing i pushed for durign the pmem stuff which alex_xu and other kindly implemented | |
| 15:01:22 | artom | sean-k-mooney, so yeah, NUMA in placement would be nice, and would solve a whole bunch of problems, but it's a mess to make work, so here we are ^_^ | |
| 15:02:07 | sean-k-mooney | this really doesnt have that much to do with numa in placment although this generic resouce field would allow use to too remove teh numa blobs if we had that | |
| 15:02:42 | sean-k-mooney | we would still have to do the resouce tracking in the db using this but its an alternitive | |
| 15:02:59 | sean-k-mooney | im not sure its worth the work to move it | |
| 15:03:34 | sean-k-mooney | but for example if we start support vdpa devices in the futrue | |
| 15:03:55 | sean-k-mooney | i would proably look to use this or extend the pci tracker | |
| 15:04:19 | sean-k-mooney | (just the type filed) | |
| 15:04:40 | sean-k-mooney | but we should not need to modify the db to add support for vdpa | |
| 15:05:06 | sean-k-mooney | or if we wanted to add orther host device passhtough support like block devices or usb devices | |
| 15:05:16 | sean-k-mooney | the resouce filed can be used for that | |
| 15:07:15 | sean-k-mooney | the limitation is that to use it you have to frist track the resouce in placment | |
| 15:13:55 | artom | sean-k-mooney, yeah, I meant more in the general sense of "using placement for atomic resource tracking" | |
| 15:14:10 | sean-k-mooney | artom: well it will never actully do that | |
| 15:14:19 | sean-k-mooney | it will track capastity | |
| 15:14:24 | sean-k-mooney | but not indiviual resouces | |
| 15:14:25 | artom | sean-k-mooney, yeah, inventories | |
| 15:14:36 | artom | (In retrospect, maybe that was a mistake?) | |
| 15:14:50 | sean-k-mooney | it was a deliberate design choice | |
| 15:14:55 | artom | I know | |
| 15:15:07 | sean-k-mooney | we knew the concequece was the resouce tracker would alwys be needed for assignment | |
| 15:15:15 | artom | Just saying, maybe not the correct one to make - though obviously hindsight is 20/20, yadda yadda | |
| 15:15:48 | openstackgerrit | Merged openstack/nova stable/rocky: libvirt: Provide VIR_MIGRATE_PARAM_PERSIST_XML during live migration https://review.opendev.org/747975 | |
| 15:15:51 | sean-k-mooney | it not a hignsight thing we knew the resouce treacker and some level of assignment logic woudl be needed in nova | |
| 15:16:03 | openstackgerrit | Merged openstack/nova stable/ussuri: Removed the host FQDN from the exception message https://review.opendev.org/749607 | |
| 15:16:09 | openstackgerrit | Merged openstack/nova master: privsep: Add support for recursive chown, move_tree operations https://review.opendev.org/742864 | |
| 15:16:57 | sean-k-mooney | to be clear we coudl use palcment for indeivigual resouce tracking if we wanted via nesting and many many more resouce providers | |
| 15:17:24 | artom | Eww | |
| 15:17:29 | artom | sean-k-mooney, anyways, it's all moot at this point | |
| 15:17:29 | sean-k-mooney | its flexable enough to do that but we chose not too | |
| 15:49:20 | artom | Whoever did that is awesome | |
| 15:53:45 | gibi | nova meeting starts in 6 minutes on openstack-meeting-3 | |
| 16:00:18 | lyarwood | artom: it's great but I'd also love to write a script to open everything in vim (over http) using the raw links | |
| 16:01:02 | artom | lyarwood, ... everything? | |
| 16:01:04 | sean-k-mooney | lyarwood: i think lnav support direct links | |
| 16:01:31 | sean-k-mooney | it would automaticaly syntax highlith and alinge all the logs by time stamp too if that worked | |
| 16:02:44 | lyarwood | artom: well not everything but the stuff I typically look at, so n-* logs, tempest logs etc | |
| 16:02:59 | sean-k-mooney | anything ending in log | |
| 16:03:21 | sean-k-mooney | oh i guess most end in .txt | |
| 16:04:23 | sean-k-mooney | ah the gzip compression mess up usin lnav and likely vim with the raw urls | |
| 16:08:43 | lyarwood | sean-k-mooney: vim WORKSFORME with gzip FWIW | |
| 16:08:58 | sean-k-mooney | lyarwood: gzip is not the issue | |
| 16:09:09 | sean-k-mooney | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_557/746986/3/check/nova-live-migration/557b715/logs/screen-n-cpu.txt | |
| 16:09:17 | sean-k-mooney | us being served compressed | |
| 16:09:31 | lyarwood | ah yeah that borks vim | |
| 16:09:37 | sean-k-mooney | yep | |
| 16:10:01 | sean-k-mooney | vim and lnave are not reading the hearer or it is not serving it with the writh header | |
| 16:10:36 | lyarwood | I think vim just calls out to wget tbh | |
| 16:10:42 | sean-k-mooney | ya its being served tih text/plain and Content-encoding gzip | |
| 16:10:46 | lyarwood | at least it does for me but that could be a plugin | |
| 16:11:18 | sean-k-mooney | yep so lnav and vim would have to use teh Accepts-encode header to not allow copression | |
| 16:11:34 | sean-k-mooney | or read the respocne head and do the right thing | |
| 16:12:11 | sean-k-mooney | that said just localy donloadingthm to somewhere in /tmp and then passing the paths to vim or lnav works | |
| 16:31:36 | openstack | bug 1894095 in OpenStack Compute (nova) "Running periodic task during live migration results in incorrect usage" [Medium,Confirmed] https://launchpad.net/bugs/1894095 - Assigned to Stephen Finucane (stephenfinucane) | |
| 16:31:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add reproducer for bug #1894095 https://review.opendev.org/749713 | |
| 16:37:09 | gibi | sean-k-mooney: can I pull the trigger on the os-vif release https://review.opendev.org/#/c/749535/ ? | |
| 16:40:48 | artom | lyarwood, so actually our volume thing with whitebox is different - it's a test for detaching a volume with libvirt stopped, so we expect the volume to remain in-use until libvirt starts up again and the detach completes. Did that behaviour change? | |
| 16:45:03 | sean-k-mooney | gibi: ya i think so | |
| 16:45:10 | gibi | sean-k-mooney: ack | |
| 16:45:21 | sean-k-mooney | the two patches i was waiting for are still not merged but they need rework | |
| 16:45:27 | sean-k-mooney | so we will just backport them later | |
| 16:45:32 | gibi | OK, done | |
| 16:45:35 | lyarwood | artom: when you say completes is the disk detached from the domain? | |
| 16:45:40 | lyarwood | artom: or just detached in cinder | |
| 16:46:14 | artom | lyarwood, cinder | |
| 16:46:19 | lyarwood | artom: if libvirt is stopped the call to detach should fail but AFAIK we should then rollback the volume state to in-use | |
| 16:46:27 | lyarwood | artom: if we don't that's a bug | |
| 16:47:00 | artom | lyarwood, ok, I'll dig some more then - looks like it's only happening with focal | |
| 16:47:09 | artom | For all I know we're stopping libvirt wrong :P | |
| 16:47:22 | lyarwood | huh, might be the error raised from the libvirt python lib has changed | |
| 16:47:29 | lyarwood | when it can't talk to libvirtd | |
| 16:47:33 | lyarwood | or some weirdness like that | |
| 16:54:27 | gibi | dansmith: lyarwood: thanks for taking care of the rbd documentation | |
| 16:54:53 | gmann | lyarwood: you can use this patch also which unskip the tests - https://review.opendev.org/#/c/734029/ | |
| 16:55:02 | gmann | devstack-platform-focal job run those test on focal | |
| 16:55:40 | artom | lyarwood, ah, no, looks like systemctl is configured in focal to restart libvirtd if it dies? | |
| 16:55:51 | artom | In any case, something starts it back up again, 3 seconds afer we stop it | |
| 16:55:55 | gibi | artom: thanks for the review on https://review.opendev.org/#/c/748453/ I can try to add a functional test for that later, if that is OK | |
| 16:56:16 | artom | gibi, I think we're better off reviewing stephenfin's series first | |
| 16:56:25 | artom | Then adding on to it | |
| 16:56:51 | lyarwood | gmann: ack thanks | |
| 16:56:54 | lyarwood | artom: kk | |
| 16:56:57 | lyarwood | gibi: np | |
| 16:59:34 | gibi | artom: make sense | |
| 16:59:44 | gibi | artom: I will try to get to that series | |
| 16:59:57 | artom | gibi, same here | |
| 17:00:05 | artom | There's a lot there to unpack | |
| 17:03:53 | sean-k-mooney | atuclly i was hoping we could merge the sriov feature first | |
| 17:04:03 | sean-k-mooney | because im not sure we will get both done by m3 | |
| 17:04:35 | sean-k-mooney | so put stephens changes on top of gibis? | |
| 17:05:27 | sean-k-mooney | that way we can avoid the merge conflitcs and still review them all in context? | |
| 17:05:31 | artom | sean-k-mooney, yeah, I was saying the same thing | |
| 17:05:48 | gibi | I would not rush with that move, as I lost my whole afternoon downstream today. I think if we approve both and then there is a conflict we can decide which one to move | |
| 17:05:54 | artom | sean-k-mooney, gibi, 1. merge SRIOV 2. merge stephenfin func tests 3. improve func tests to cover the case gibi is fixing | |
| 17:06:19 | gibi | in general I agree | |
| 17:06:30 | artom | And 4. convert SRIOV live migration to use claims like NUMA live migration, giving sean-k-mooney an aneurysm in the process ;) | |
| 17:06:38 | gibi | It is just hard to commit to 1. right now as I still have a list of func test to write | |
| 17:06:53 | sean-k-mooney | :) | |
| 17:07:16 | gibi | please don't kill each other over it, I need both of you in this team! | |
| 17:07:36 | artom | Nah, we'll just have an honest drinking competition for it | |