| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-15 | |||
| 09:55:55 | gibi | I notified the author of the test case and he promised to check it | |
| 09:55:55 | gibi | I notified the author of the test case and he promised to check it | |
| 10:56:14 | openstackgerrit | Balazs Gibizer proposed openstack/placement master: Add support for RP re-parenting and orphaning https://review.opendev.org/c/openstack/placement/+/784020 | |
| 11:14:14 | noonedeadpunk | Hi! Can you kindly help me a bit. I'm just trying to understand why we might be doing certain thing and it feels for me that it's not needed nowadays. But decided to ask before changing behaviour | |
| 11:14:14 | noonedeadpunk | Hi! Can you kindly help me a bit. I'm just trying to understand why we might be doing certain thing and it feels for me that it's not needed nowadays. But decided to ask before changing behaviour | |
| 11:15:36 | noonedeadpunk | So we're running `nova-manage cell_v2 map_instances` after creating a cell. I think that might be the valid case in old releases, when cellsv2 were just introduced? | |
| 11:15:36 | noonedeadpunk | So we're running `nova-manage cell_v2 map_instances` after creating a cell. I think that might be the valid case in old releases, when cellsv2 were just introduced? | |
| 11:16:02 | noonedeadpunk | or, when you create new cell and aim to move instances there? | |
| 11:16:02 | noonedeadpunk | or, when you create new cell and aim to move instances there? | |
| 11:30:46 | sean-k-mooney | you should not need to do map instance every upgrade | |
| 11:30:46 | sean-k-mooney | you should not need to do map instance every upgrade | |
| 11:31:15 | sean-k-mooney | just if you are going form non cellsv2 to cellv2 i belive | |
| 11:31:15 | sean-k-mooney | just if you are going form non cellsv2 to cellv2 i belive | |
| 11:31:17 | noonedeadpunk | yeah, that;s what I thought... And also there's batches of 50 instances anyway | |
| 11:31:17 | noonedeadpunk | yeah, that;s what I thought... And also there's batches of 50 instances anyway | |
| 11:31:43 | noonedeadpunk | (so would need to run in a while cycle or smth like that) | |
| 11:31:43 | noonedeadpunk | (so would need to run in a while cycle or smth like that) | |
| 11:31:58 | noonedeadpunk | sean-k-mooney: thanks for confirming my concerns | |
| 11:31:58 | noonedeadpunk | sean-k-mooney: thanks for confirming my concerns | |
| 11:33:02 | sean-k-mooney | the discover_hosts command also only need to be run if you add/remove hosts | |
| 11:33:02 | sean-k-mooney | the discover_hosts command also only need to be run if you add/remove hosts | |
| 11:33:11 | sean-k-mooney | or i guess move them | |
| 11:33:11 | sean-k-mooney | or i guess move them | |
| 11:34:07 | noonedeadpunk | I think discover_hosts shouldn't actually hurt? As I'm not sure about how to distinguish if we add host atm or not... | |
| 11:34:07 | noonedeadpunk | I think discover_hosts shouldn't actually hurt? As I'm not sure about how to distinguish if we add host atm or not... | |
| 11:34:16 | sean-k-mooney | although you nomally dont move host between cells. you can but its not common and it proably adviasble ot not have vms on it if you do | |
| 11:34:16 | sean-k-mooney | although you nomally dont move host between cells. you can but its not common and it proably adviasble ot not have vms on it if you do | |
| 11:34:40 | sean-k-mooney | noonedeadpunk: ya its pretty cheap | |
| 11:34:40 | sean-k-mooney | noonedeadpunk: ya its pretty cheap | |
| 11:34:54 | sean-k-mooney | noonedeadpunk: ooo i think just always runs it | |
| 11:34:54 | sean-k-mooney | noonedeadpunk: ooo i think just always runs it | |
| 11:35:11 | sean-k-mooney | noonedeadpunk: we even have the option to do it as a perodic task if you really want too | |
| 11:35:11 | sean-k-mooney | noonedeadpunk: we even have the option to do it as a perodic task if you really want too | |
| 11:35:30 | noonedeadpunk | Yeah, I know. It's just smth like 20mins or so iirc | |
| 11:35:30 | noonedeadpunk | Yeah, I know. It's just smth like 20mins or so iirc | |
| 12:07:15 | lyarwood | gibi: re https://review.opendev.org/c/openstack/nova/+/770246 I forgot to note that I wanted to land https://review.opendev.org/c/openstack/nova/+/785682 first if possible, I think it's valid to also cover that corner case in the event based flow as well. | |
| 12:07:15 | lyarwood | gibi: re https://review.opendev.org/c/openstack/nova/+/770246 I forgot to note that I wanted to land https://review.opendev.org/c/openstack/nova/+/785682 first if possible, I think it's valid to also cover that corner case in the event based flow as well. | |
| 12:24:52 | gibi | lyarwood: looking | |
| 12:24:53 | gibi | lyarwood: looking | |
| 12:26:40 | gibi | lyarwood: I will do the rebase and the adaptation to your fix either today or tomorrow | |
| 12:26:40 | gibi | lyarwood: I will do the rebase and the adaptation to your fix either today or tomorrow | |
| 12:27:38 | lyarwood | gibi: ack thanks, I'll go over the rest of the series later in more detail but clicking through it LGTM at the moment | |
| 12:27:38 | lyarwood | gibi: ack thanks, I'll go over the rest of the series later in more detail but clicking through it LGTM at the moment | |
| 12:27:59 | gibi | cool, I will +A your fix soon | |
| 12:27:59 | gibi | cool, I will +A your fix soon | |
| 13:12:28 | mnaser | bauzas: https://bugs.launchpad.net/nova/+bug/1900800 have you thought about how this can be resolved? We are running into this often :( | |
| 13:12:29 | mnaser | bauzas: https://bugs.launchpad.net/nova/+bug/1900800 have you thought about how this can be resolved? We are running into this often :( | |
| 13:12:32 | openstack | Launchpad bug 1900800 in OpenStack Compute (nova) "VGPUs is not recreated on host reboot" [Low,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:41:18 | bauzas | mnaser: sorry I was on a meeting | |
| 13:41:18 | bauzas | mnaser: sorry I was on a meeting | |
| 13:41:52 | bauzas | mnaser: well, maybe we would need to ask the operator to create the mdevs after rebooting | |
| 13:41:52 | bauzas | mnaser: well, maybe we would need to ask the operator to create the mdevs after rebooting | |
| 13:49:12 | openstackgerrit | Qiu Fossen proposed openstack/nova-specs master: Allow migrating PMEM's data https://review.opendev.org/c/openstack/nova-specs/+/785563 | |
| 13:51:32 | sean-k-mooney | bauzas: the mdevs should be create in init_host today | |
| 13:51:32 | sean-k-mooney | bauzas: the mdevs should be create in init_host today | |
| 13:51:57 | sean-k-mooney | oh | |
| 13:51:57 | sean-k-mooney | oh | |
| 13:52:10 | bauzas | sean-k-mooney: the problem is that we don't know which mdev type they usze | |
| 13:52:10 | bauzas | sean-k-mooney: the problem is that we don't know which mdev type they usze | |
| 13:52:49 | sean-k-mooney | well we should no? | |
| 13:52:49 | sean-k-mooney | well we should no? | |
| 13:53:05 | sean-k-mooney | the mdevs should still be in the domins | |
| 13:53:05 | sean-k-mooney | the mdevs should still be in the domins | |
| 13:53:12 | sean-k-mooney | this should be running before we start the vms | |
| 13:53:12 | sean-k-mooney | this should be running before we start the vms | |
| 13:53:22 | sean-k-mooney | oh the type is not recorded | |
| 13:53:22 | sean-k-mooney | oh the type is not recorded | |
| 13:53:33 | sean-k-mooney | so if you have multiple devices that would be an issue | |
| 13:53:33 | sean-k-mooney | so if you have multiple devices that would be an issue | |
| 13:54:02 | sean-k-mooney | although we would be abel to look at the vgpu request in the flavor if you had a traits request | |
| 13:54:02 | sean-k-mooney | although we would be abel to look at the vgpu request in the flavor if you had a traits request | |
| 13:54:12 | sean-k-mooney | or better yet the allocation summeries | |
| 13:54:12 | sean-k-mooney | or better yet the allocation summeries | |
| 13:55:29 | sean-k-mooney | we can look up the RP form which the allocation came from and then identify the partent device and use that to look up the mdev type in the config | |
| 13:55:29 | sean-k-mooney | we can look up the RP form which the allocation came from and then identify the partent device and use that to look up the mdev type in the config | |
| 13:55:42 | sean-k-mooney | bauzas: that should work right ^ | |
| 13:55:42 | sean-k-mooney | bauzas: that should work right ^ | |
| 13:55:50 | bauzas | sean-k-mooney: the problem is that the traits are optional | |
| 13:55:50 | bauzas | sean-k-mooney: the problem is that the traits are optional | |
| 13:55:58 | sean-k-mooney | we dont need the traits | |
| 13:55:58 | sean-k-mooney | we dont need the traits | |
| 13:56:20 | sean-k-mooney | use allcotion to figure out partent device use parent device to look up mdev type in nova.conf | |
| 13:56:20 | sean-k-mooney | use allcotion to figure out partent device use parent device to look up mdev type in nova.conf | |
| 13:56:23 | sean-k-mooney | then recreate it | |
| 13:56:23 | sean-k-mooney | then recreate it | |
| 13:56:51 | bauzas | sean-k-mooney: https://github.com/openstack/nova/blob/450213f/nova/virt/libvirt/driver.py#L816 | |
| 13:56:51 | bauzas | sean-k-mooney: https://github.com/openstack/nova/blob/450213f/nova/virt/libvirt/driver.py#L816 | |
| 13:57:33 | bauzas | here, we would then need to call placement | |
| 13:57:33 | bauzas | here, we would then need to call placement | |
| 13:57:40 | sean-k-mooney | yes | |
| 13:57:54 | sean-k-mooney | unless we have the allocation summeries saved somewhere | |
| 13:57:54 | sean-k-mooney | unless we have the allocation summeries saved somewhere | |
| 13:58:11 | sean-k-mooney | i.e. in the nova db but we dont as far as i know | |
| 13:58:11 | sean-k-mooney | i.e. in the nova db but we dont as far as i know | |
| 13:58:12 | bauzas | ok, but then we would see VGPU allocations | |
| 13:58:12 | bauzas | ok, but then we would see VGPU allocations | |
| 13:58:23 | bauzas | for RP | |
| 13:58:23 | bauzas | for RP | |
| 13:58:25 | bauzas | for a RP | |
| 13:58:25 | bauzas | for a RP | |