| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-23 | |||
| 19:00:30 | sean-k-mooney | but beign realisting if you need this quick | |
| 19:00:52 | sean-k-mooney | then likely createing a poc and upstreaming it next cycle is what your going to have to do | |
| 19:01:32 | sean-k-mooney | for the poc you could do the hack where you fix up the adresses | |
| 19:01:32 | deke997 | One thing to check on: | |
| 19:01:52 | deke997 | I think cyborg is doing some stuff with multi function too | |
| 19:01:59 | deke997 | I saw it while doing research | |
| 19:02:04 | sean-k-mooney | ya so cyborg would be another option | |
| 19:02:15 | sean-k-mooney | if the integration is done this cycle | |
| 19:02:34 | sean-k-mooney | then you could write a device dirver for you custom multifunion device | |
| 19:02:50 | sean-k-mooney | but the xml change would still need to be done | |
| 19:03:03 | sean-k-mooney | you would not have to touch the filer or pci manager in that case | |
| 19:03:14 | sean-k-mooney | but you would need to do all the cyborg work | |
| 19:04:51 | sean-k-mooney | deke997: cyborg support in nova is planned for this cycle but we said that last cycle too | |
| 19:05:02 | sean-k-mooney | deke997: its much closer to being read this time however | |
| 19:06:35 | deke997 | Good to know | |
| 19:07:48 | deke997 | I need to look into how they're implementing multi function a bit more | |
| 19:08:13 | deke997 | but even so, I can't wait till the next cycle to get a beta working here | |
| 19:09:05 | sean-k-mooney | at present without the libvirt support for multifuntion devices in nova cybporg cant support what you need | |
| 19:09:06 | deke997 | I think the options in order of increasing time, complexity, and correctness would probably be | |
| 19:09:17 | deke997 | 1. hack | |
| 19:09:22 | deke997 | 2. nova | |
| 19:09:24 | deke997 | 3. cyborg | |
| 19:09:58 | sean-k-mooney | 0 heiring an intern to manually update every vm as it spawns | |
| 19:10:07 | deke997 | hahahah | |
| 19:10:13 | deke997 | but I can't even do that | |
| 19:10:32 | sean-k-mooney | actully there is one other hack you cloud do | |
| 19:10:32 | deke997 | the xml changes don't go into effect till you reboot | |
| 19:10:46 | deke997 | and when you reboot, it gets overwritten | |
| 19:11:07 | deke997 | is there a way to make the xml changes before boot? or to make the changes go live while the instance is running? | |
| 19:11:32 | sean-k-mooney | for reasons in the past i did have need to do horible things | |
| 19:11:36 | sean-k-mooney | https://opendev.org/x/networking-ovs-dpdk/src/branch/master/devstack/libs/ovs-dpdk#L79-L130 | |
| 19:12:16 | sean-k-mooney | that is an example of a script that replace the qemu executable and rewrites the qemu commandline on the fly | |
| 19:13:39 | sean-k-mooney | what that sciprt is acatlly doing is making sure nic offload that did not work with ancnet version of qemu and ovs-dpdk are disabeld and it makes ure the guest memory has the mmap shared flag set | |
| 19:14:25 | sean-k-mooney | you could install a qemu wrapper script as a hack to match on parts of the qemu command line and alter it | |
| 19:14:46 | sean-k-mooney | it would have 0 support form anyone but it is a -1 on your scale | |
| 19:17:04 | deke997 | haha i'll have to look into that too i guess | |
| 19:17:38 | sean-k-mooney | adding flags to existing optins is nasty but actully kind of simple | |
| 19:17:51 | sean-k-mooney | doing what you need to do would be harder | |
| 19:18:18 | sean-k-mooney | but at the end of the day the commandline is fairly deterministic so it would be doable | |
| 19:18:36 | sean-k-mooney | definelty not my first choise but we dont always get to do our first choice | |
| 19:19:57 | deke997 | I'll see what I can figure out tonight and get back to you soon with the progress | |
| 19:20:07 | deke997 | lmk if you have any other ideas | |
| #openstack-nova - 2020-01-24 | |||
| 10:05:01 | lyarwood | ?pyyamk | |
| 10:05:08 | lyarwood | whops sorry | |
| 10:54:07 | stephenfin | efried: Looking through that now. A few of them look like races ("The specified subnet does not have enough free addresses to satisfy the request.") but yet more might be issues ("Unknown error occurred."). Will keep rooting | |
| 14:23:43 | gibi | dansmith: I've replied to your comments in https://review.opendev.org/#/c/702261/ | |
| 14:24:28 | artom | gibi, according to our internal PTO calendar, he's off in the woods somewhere | |
| 14:25:25 | gibi | artom: thanks. | |
| 14:28:32 | gibi | lyarwood: coud you re-review https://review.opendev.org/#/c/702181/ as you were +2 before but I fixed comments from elod | |
| 14:38:01 | bauzas | why for gosh's sake we aren't using the same driver method for finishing a resize and finishing a resize revert ? graaaah | |
| 14:45:58 | lyarwood | gibi: done, thanks! | |
| 14:46:13 | lyarwood | random Friday question, do we not have an ImageService fixture? | |
| 14:46:37 | gibi | lyarwood: thanks! | |
| 14:47:15 | gibi | lyarwood: nova.tests.unit.image.fake._FakeImageService | |
| 14:47:46 | bauzas | gibi: could you please remind me, in the case of a resize revert, the target allocation is still against the instance while the source allocation is still against the migration (like a standard resize, right?) | |
| 14:48:04 | lyarwood | gibi: ah it's in unit, no wonder I couldn't find it thanks! | |
| 14:48:06 | gibi | lyarwood: it is basically a manual fixture pulled in by calling nova.tests.unit.image.fake.stub_out_image_service | |
| 14:48:26 | lyarwood | gibi: ack thanks | |
| 14:48:48 | gibi | bauzas: at the start of revert the dest allocation is held by the instance the source allocation is held by the migration | |
| 14:49:10 | bauzas | gibi: even during _finish_revert_resize ? | |
| 14:49:25 | gibi | bauzas: good question, let me find where we revert the allocation | |
| 14:49:33 | bauzas | gibi: I'm hands on code | |
| 14:49:36 | bauzas | gibi: lemme look | |
| 14:50:02 | bauzas | gibi: found | |
| 14:50:03 | bauzas | sec | |
| 14:51:04 | gibi | it is in the compute manager finish_rever_resize where we reverting the allocation | |
| 14:51:51 | bauzas | right, I was about to paste this | |
| 14:52:01 | bauzas | and *before* we call the driver method for finishing it | |
| 14:52:08 | bauzas | which is important | |
| 14:52:32 | gibi | yep, driver call comes after the alloc revert | |
| 14:52:35 | openstack | Launchpad bug 1778563 in OpenStack Compute (nova) "Resize/Cold-migrate doesn't recreate vGPUs" [High,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 14:52:35 | bauzas | gibi: context being https://bugs.launchpad.net/nova/+bug/1778563 | |
| 14:53:00 | bauzas | which means I also have to consider the revert resize case | |
| 14:54:40 | bauzas | gibi: do you remember when we delete the migration allocation on a revert (since we don't have a revert confirm AFAIK) | |
| 14:54:46 | gibi | when you migrate on the dest host you need to set up the vgpu resources, but when you revert the vgpu resource on the source host still has to be allocated | |
| 14:55:07 | bauzas | gibi: yeah, that's something I have to keep | |
| 14:55:17 | bauzas | we're doubling the needed vgpus | |
| 14:55:18 | gibi | bauzas: but isn't it kept automatically? | |
| 14:55:35 | bauzas | gibi: when you resize, we regenerate a new libvirt XML | |
| 14:55:42 | bauzas | gibi: without using the existing mdevs | |
| 14:55:52 | bauzas | gibi: so the mdevs are there, but unallocated | |
| 14:56:43 | gibi | before resize confirm I expect that both the source and the dest host has an instance xml with mdevs so revert does not need to recreate the instance xml on the soruce | |
| 14:59:02 | gibi | bauzas: actually the _revert_allocation call in the finish_rever_resize delets the migration allocation by moving the allocation from the migration.uuid to the instance.uuid | |
| 14:59:11 | gibi | so the migration.uuid will not have any allocation left | |
| 14:59:29 | gibi | and dest allocation is overwritten by the source allocation during the move | |
| 15:27:44 | gibi | stephenfin: how do you feel about the usefulness of the schema for nova in https://review.opendev.org/#/c/703133 based on Ilya's answer to my clarification question? | |
| 15:29:17 | gibi | stephenfin: I'm a bit hesitant but convincable to look into forgeing a test case that validates nova generated metadata against the stored schema during a libvirt based func test | |
| 15:30:27 | stephenfin | gibi: Yeah, I'd be in the same frame of mind. If there's a test, it's not a huge burden and it's helpful to someone, sure, why not | |
| 15:30:40 | stephenfin | just so long as _I_ don't have to write that test :) | |
| 15:31:27 | gibi | I see. :) It is friday afternoon so I think I will not start any big thing for this week but I can at least try my test idea out before the weekend | |
| 17:48:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Test network_data.json schema https://review.opendev.org/704182 | |
| 17:48:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add JSON schema for network_data.json https://review.opendev.org/703133 | |
| 17:49:10 | gibi | stephenfin: my stab at the problem ^^ | |
| 17:51:35 | gibi | I failed to include the metadata service into existing normal functinal test (it made the test stop for ever at the fixture setup) but I was able beef up the existing MetadataTest class with a real instance | |
| 17:51:55 | gibi | and with that I stop my work week, see you on Monday | |
| 17:52:14 | sean-k-mooney | enjoy the weekend | |
| 17:52:34 | gibi | sean-k-mooney: same to you | |
| 17:52:42 | sean-k-mooney | stephen left an hour ago | |
| 19:55:23 | openstackgerrit | Merged openstack/nova stable/stein: Mask the token used to allow access to consoles https://review.opendev.org/702181 | |
| #openstack-nova - 2020-01-25 | |||
| 00:44:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ensure source compute is up when confirming a resize https://review.opendev.org/699291 | |