| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-26 | |||
| 10:47:49 | kashyap | More power to you. | |
| 10:48:09 | kashyap | JOMO++ (joy of missing out) | |
| 10:48:14 | bauzas | hell yeah, and Facebook is just very little used | |
| 10:48:45 | bauzas | kashyap: never read Asimov N | |
| 10:48:46 | bauzas | ? | |
| 10:49:20 | bauzas | this is vast, I'd recomment you to start with Foundation's Prelude to get a chronological view instead of a publication view | |
| 10:49:36 | bauzas | but you'd also have to read some other books | |
| 10:49:42 | kashyap | bauzas: No. The only sci-fi I've ever read is Iain M. Banks' Culture series | |
| 10:49:48 | bauzas | the Robots cycle, obviously | |
| 10:50:04 | kashyap | Noted :) Thx for the reco | |
| 10:50:12 | bauzas | but there are also some books very worthy between the Robots period and the Foundation perioid | |
| 10:50:43 | bauzas | sweating* even | |
| 10:59:21 | sean-k-mooney[m] | kashyap your missing out. i “read” mostly via audio books on audible. i have complete abour 280 ish books in the last 6 years almost all are sifi/space opera/lit rpg or are fantasy. as someone with dislexia who has preverisly only read a hand full of books every audio books really work for me | |
| 10:59:59 | kashyap | sean-k-mooney[m]: Yeah, I'll completely believe you. And I'm glad that you're able to enjoy audio books | |
| 11:01:28 | sean-k-mooney[m] | that remiands me i think a new book in one of the series im following is out soon i should check | |
| 11:01:53 | kashyap | sean-k-mooney[m]: On missing out; I hear ya. I mostly read (physical) books in the area of "cognitive science": neuroscience, psychology, primate/human behaviour, biology, ancient Greek/Roman philosophy, and linguistics :D | |
| 11:02:13 | kashyap | I do read fiction; but have reduced it a lot. I should get back to it a bit more, to lighten up the mood :) | |
| 11:02:49 | kashyap | sean-k-mooney[m]: For audio, I listen to 90-minute podcasts, but haven't yet tried a proper audiobook. I'll really need to give it a go | |
| 11:03:04 | kashyap | Thanks for the reminder! | |
| 11:03:55 | lyarwood | bauzas / sean-k-mooney ; https://review.opendev.org/c/openstack/nova/+/815373 - I think I've got my head around this, it's weird but I guess it's valid as a bugfix. Would appreciate review and maybe some TODO fups from someone setting out a better solution that doesn't rely on the persistent domain XML. | |
| 11:06:24 | kashyap | lyarwood: "The | |
| 11:06:31 | kashyap | ... limitation has been lifted since then" -- is that in libvirt? | |
| 11:06:37 | kashyap | (From the commit message) | |
| 11:06:51 | sean-k-mooney[m] | i think in qemu | |
| 11:06:52 | lyarwood | Yeah correct, they didn't list the version in the commit message but it's in the releasenote | |
| 11:06:53 | kashyap | The hot-unplug of mediated device, i.e. | |
| 11:07:10 | lyarwood | and yeah I'm sure it's both libvirt and QEMU | |
| 11:07:10 | sean-k-mooney[m] | basicaly nova managed save did not support mdevs | |
| 11:07:11 | kashyap | sean-k-mooney[m]: It's libvirt, the previous sentence talks of libvirt | |
| 11:07:25 | kashyap | lyarwood: Yeah; that's also correct, actually. | |
| 11:07:44 | sean-k-mooney[m] | *libvirt managed save | |
| 11:08:09 | kashyap | Yea | |
| 11:08:10 | sean-k-mooney[m] | kashyap well the libvirt limitation was becasue of a qemu limitation i belive | |
| 11:08:21 | sean-k-mooney[m] | anyway now they do supprot | |
| 11:08:42 | sean-k-mooney[m] | it so we dont need too or want too detach the mdevs right | |
| 11:08:54 | sean-k-mooney[m] | but resume need to support both the new and old behavior | |
| 11:09:06 | kashyap | (Yeah; I said it could be both a follow-up above.) | |
| 11:11:04 | sean-k-mooney[m] | ack | |
| 11:11:17 | sean-k-mooney[m] | i have not reviewd that patch closely by the way | |
| 11:13:31 | sean-k-mooney[m] | at the end of the day i still think we should be tracking the mdevs in novas db and recreating form the db record instead of trying to use the guest xml to store the mdevs used | |
| 11:13:38 | opendevreview | Merged openstack/nova master: Updating tests with Yoga testing runtime https://review.opendev.org/c/openstack/nova/+/819194 | |
| 11:14:19 | sean-k-mooney[m] | e.g. right now we are relying on the domain to exist to prevent other vms from using the mdevs which is fragile | |
| 11:16:15 | sean-k-mooney[m] | at least in comparison to storing them in the resoucs table or pci devices table. it has the advantage of being local i guess but it make reaning about this harder since we dont track the arent device ectra in other edge cases like host reboot | |
| 11:16:40 | sean-k-mooney[m] | so i hope we can make this simpler and just recored it in the db eventurally | |
| 11:18:27 | lyarwood | Yeah agreed, I think for now this is a valid backportable fix but really it needs to be replaced by something from our DB or placement or something | |
| 11:19:11 | lyarwood | It's just super confusing given we detach from the active and then use the persistent domain to work out what we need to reattach before we then restore the managedSave state of the domain | |
| 11:20:17 | lyarwood | I guess an alternative is for libvirt to support managedSave somehow for mdevs, likely by the caller telling it not to care about their state or something? | |
| 11:20:44 | sean-k-mooney[m] | so i think it dose now right ? | |
| 11:21:14 | sean-k-mooney[m] | oh no | |
| 11:21:40 | sean-k-mooney[m] | what has changed is we blocked suspend before becaue we could not unplug and replug the mdev | |
| 11:21:44 | sean-k-mooney[m] | now we can | |
| 11:23:41 | sean-k-mooney[m] | oh there is another nasty bug there | |
| 11:24:02 | sean-k-mooney[m] | so we previously detach the interface on suspend right | |
| 11:24:49 | sean-k-mooney[m] | now we are reattaching them when we did not before which is good | |
| 11:25:07 | sean-k-mooney[m] | but we sometimes suspend the guest when we do snapshot | |
| 11:25:36 | sean-k-mooney[m] | so as a side effect if you could not use live snap shots snapshotting would remove the mdev and not reattach them | |
| 11:25:51 | sean-k-mooney[m] | so this will fix that too | |
| 11:26:32 | opendevreview | Lee Yarwood proposed openstack/nova master: fup: Require python >= 3.8 from Yoga https://review.opendev.org/c/openstack/nova/+/819415 | |
| 11:27:27 | lyarwood | do we use suspend for that? | |
| 11:27:36 | lyarwood | I thought that was a pause on the domain itself | |
| 11:28:02 | lyarwood | ah it's suspend | |
| 11:28:03 | lyarwood | TIL | |
| 11:28:53 | lyarwood | okay yeah resume needs to be updated | |
| 11:29:02 | sean-k-mooney[m] | ya i tought it would be pause too untile i read it again just now. | |
| 11:29:06 | lyarwood | https://github.com/openstack/nova/blob/d630615a02469442fb50ed4aa7e092206a28166a/nova/virt/libvirt/driver.py#L3043-L3063 that even | |
| 11:29:10 | lyarwood | nice catch | |
| 11:29:42 | lyarwood | tbh the TODO from stephenfin is right, that could just be a single call to self.resume | |
| 11:30:07 | sean-k-mooney[m] | actully i tought that just called resume like the suppoed_for_snappshot calls suspend | |
| 11:30:22 | sean-k-mooney[m] | ya | |
| 11:30:41 | sean-k-mooney[m] | it should be. | |
| 11:38:57 | opendevreview | Lee Yarwood proposed openstack/nova master: DNM Testing python >= 3.8 requirement https://review.opendev.org/c/openstack/nova/+/819432 | |
| 11:50:49 | sean-k-mooney | lyarwood:... unfortunetly we might need to keey requires_python>=3.6 for rdo this cycle due to upgrdes | |
| 11:51:12 | sean-k-mooney | which makes me think we cant actully turn off testin 3.6 until z | |
| 11:51:21 | lyarwood | Why would we need to keep it? | |
| 11:51:45 | sean-k-mooney | because they will be supprot yoga on centos 8 and 9 for upgrades | |
| 11:51:45 | lyarwood | Can't we just ship py38 in the Yoga containers? | |
| 11:52:18 | sean-k-mooney | we can but they ahve to supprot rpm install. and to be fair 3.8 is avaiable on cents too | |
| 11:52:27 | sean-k-mooney | * centos8 too | |
| 11:52:31 | sean-k-mooney | its just not the default | |
| 11:53:08 | lyarwood | Sigh why didn't the RDO folks raise that with the TC before they moved the runtimes for Yoga | |
| 11:53:17 | lyarwood | brb | |
| 11:54:42 | sean-k-mooney | ya i dont know i really dont like the idea of our testing and min requires being differnet so i dotn know what to do to be honest | |
| 11:55:09 | lyarwood | Well for RDO at least they can workaround it easily enough | |
| 11:55:21 | lyarwood | by installing py38 alongside py36 | |
| 11:55:53 | gibi | lyarwood, bauzas: re py36 support: sorry I also missed that we are discussing that on an older PS. :/ | |
| 11:56:07 | gibi | lyarwood bauzas: I agree to land the fup on setup.cfg | |
| 11:56:17 | lyarwood | np my language here didn't help, I confused things massively | |
| 12:03:58 | gibi | and I do believ that RDO missed the deadline not to raise the issue on the TC ruling | |
| 12:09:50 | sean-k-mooney | im also kind of confused why RDO have not been testign with 3.8 as well | |
| 12:10:11 | sean-k-mooney | it has been a testing requirement for some time | |
| 12:10:38 | sean-k-mooney | i guess they were usign the lower requiremtn for centos of 3.6 | |
| 12:12:02 | sean-k-mooney | but give our downstream will be using 3.9 form wallaby+ that feels like a gap someone form redhat would have been woking on fixing | |
| 12:13:47 | sean-k-mooney | py 3.9.8 currrenlty py 3.8 will not be supproted on centos 9 | |
| 12:20:28 | lyarwood | sorry back | |
| 12:20:41 | lyarwood | just noticed I missed stephenfin 's thread about this on the ML | |
| 12:30:06 | gibi | thread even | |
| 14:19:29 | artom | Huh, looks like at some point between... victoria? and master ovs+hybrid_plug became plug-time Neutron events... | |
| 14:20:55 | artom | https://zuul.opendev.org/t/openstack/build/2f75f41da4df48f8a8abc5087fd29efb/log/controller/logs/screen-n-cpu.txt#9233 | |
| 14:23:18 | tobias-urdin | lyarwood: should we ping in somebody from RDO on the above topic or did u take it already? | |
| 14:23:51 | lyarwood | tobias-urdin: Looks like folks from RDO already raised this on the ML, I hadn't seen it until the end of the discussion earlier | |