| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-23 | |||
| 13:57:38 | lyarwood | * lyarwood is going to miss the first 20mins of the nova track talking to the manila folks | |
| 13:57:39 | sean-k-mooney | it woul apply to any vm that is not currently in shleve offloaed or error | |
| 13:57:39 | sean-k-mooney | it woul apply to any vm that is not currently in shleve offloaed or error | |
| 13:57:40 | artom | Well, for instances that are SHELVED(_OFFLOADED) for example... | |
| 13:57:40 | artom | Well, for instances that are SHELVED(_OFFLOADED) for example... | |
| 13:58:06 | sean-k-mooney | ya one that are shleve offloaded currently cant really be fixed without manual intervention | |
| 13:58:07 | sean-k-mooney | ya one that are shleve offloaded currently cant really be fixed without manual intervention | |
| 13:58:28 | artom | And don't we get into weird race conditions for instances in MIGRATING? | |
| 13:58:28 | artom | And don't we get into weird race conditions for instances in MIGRATING? | |
| 13:58:32 | gibi | lyarwood: do you have any hard opinion about droping eventlet? (we will start with that topic in nova) | |
| 13:58:32 | gibi | lyarwood: do you have any hard opinion about droping eventlet? (we will start with that topic in nova) | |
| 13:58:49 | sean-k-mooney | maybe we could determin what subset are valid in the reivew | |
| 13:58:49 | sean-k-mooney | maybe we could determin what subset are valid in the reivew | |
| 13:58:51 | artom | As in, depending on when you run the data migration, we might have already updated the port binding, or maybe we haven't | |
| 13:58:51 | artom | As in, depending on when you run the data migration, we might have already updated the port binding, or maybe we haven't | |
| 13:59:03 | sean-k-mooney | but basically any migration or command shoudl be a sperate patch after the fix | |
| 13:59:03 | sean-k-mooney | but basically any migration or command shoudl be a sperate patch after the fix | |
| 13:59:25 | sean-k-mooney | we have prescende downstream for backporting only the fix without the data migration | |
| 13:59:25 | sean-k-mooney | we have prescende downstream for backporting only the fix without the data migration | |
| 13:59:38 | sean-k-mooney | that is what we did for the network info cache force refresh | |
| 13:59:38 | sean-k-mooney | that is what we did for the network info cache force refresh | |
| 13:59:45 | artom | Oh, I remember that | |
| 13:59:45 | artom | Oh, I remember that | |
| 13:59:55 | artom | I'd argue that it can also be useful upstream | |
| 13:59:55 | artom | I'd argue that it can also be useful upstream | |
| 14:00:11 | artom | Its still fixes an issue, even if any of your pre-existing instances don't get it | |
| 14:00:11 | artom | Its still fixes an issue, even if any of your pre-existing instances don't get it | |
| 14:00:18 | sean-k-mooney | yes | |
| 14:00:20 | sean-k-mooney | i would too | |
| 14:00:20 | sean-k-mooney | i would too | |
| 14:00:34 | sean-k-mooney | that is why i want the data mighation or command in a sperate patch that is after the fix | |
| 14:00:34 | sean-k-mooney | that is why i want the data mighation or command in a sperate patch that is after the fix | |
| 14:00:45 | sean-k-mooney | so we can backport the fix only if we chosse too | |
| 14:00:45 | sean-k-mooney | so we can backport the fix only if we chosse too | |
| 14:00:50 | artom | stephenfin, you cool with that? ^^ I can push the fixes that I have for your comments, and we can figure out the online data migration thing in a separate patch? | |
| 14:00:50 | artom | stephenfin, you cool with that? ^^ I can push the fixes that I have for your comments, and we can figure out the online data migration thing in a separate patch? | |
| 14:00:51 | sean-k-mooney | to prevent new vms form breaking | |
| 14:00:51 | sean-k-mooney | to prevent new vms form breaking | |
| 14:01:27 | sean-k-mooney | then we can see how the stable team feals about backporting the nova manage command or the data migration after its fixed on master | |
| 14:01:27 | sean-k-mooney | then we can see how the stable team feals about backporting the nova manage command or the data migration after its fixed on master | |
| 14:02:08 | lyarwood | gibi: I don't :) | |
| 14:02:08 | lyarwood | gibi: I don't :) | |
| 14:02:16 | gibi | lyarwood: ack | |
| 14:07:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Test SRIOV port move operations with PCI conflicts https://review.opendev.org/c/openstack/nova/+/783084 | |
| 14:07:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/784168 | |
| 14:07:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Test SRIOV port move operations with PCI conflicts https://review.opendev.org/c/openstack/nova/+/783084 | |
| 14:07:53 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/784168 | |
| 14:08:19 | gibi | kashyap: after the current eventlet topic we will try to take your stuff from the nova etherpad | |
| 14:08:19 | gibi | kashyap: after the current eventlet topic we will try to take your stuff from the nova etherpad | |
| 14:10:43 | kashyap | gibi: Hi, I'll join in a few mins. Thanks! It's nothing super-pressing, though | |
| 14:10:43 | kashyap | gibi: Hi, I'll join in a few mins. Thanks! It's nothing super-pressing, though | |
| 14:10:56 | gibi | kashyap: ack, thanks | |
| 14:10:57 | gibi | kashyap: ack, thanks | |
| 14:39:00 | kashyap | gibi: Feel free to do the time-check :) | |
| 14:39:00 | kashyap | gibi: Feel free to do the time-check :) | |
| 14:49:43 | kashyap | How much time we have left? I'm not paying attention to the clock | |
| 14:49:43 | kashyap | How much time we have left? I'm not paying attention to the clock | |
| 15:02:19 | lyarwood | brb | |
| 15:23:50 | melwitt | bauzas: when you suggested documenting use of the os-assisted-volume-snapshots API, did you intend that for an out of tree driver? https://review.opendev.org/c/openstack/nova/+/787415 | |
| 15:23:50 | melwitt | bauzas: when you suggested documenting use of the os-assisted-volume-snapshots API, did you intend that for an out of tree driver? https://review.opendev.org/c/openstack/nova/+/787415 | |
| 15:24:55 | bauzas | melwitt: in the etherpad ? I thought lpetrut was mentioning some in-tree driver that was supporting it | |
| 15:24:55 | bauzas | melwitt: in the etherpad ? I thought lpetrut was mentioning some in-tree driver that was supporting it | |
| 15:25:13 | bauzas | but nevermind my point then | |
| 15:25:13 | bauzas | but nevermind my point then | |
| 15:25:46 | bauzas | I was confused | |
| 15:25:46 | bauzas | I was confused | |
| 15:27:35 | bauzas | melwitt: actually, apologies for the silly question but do you know the difference between https://github.com/openstack/nova/tree/master/nova/virt/hyperv and https://github.com/openstack/compute-hyperv/ ? | |
| 15:27:35 | bauzas | melwitt: actually, apologies for the silly question but do you know the difference between https://github.com/openstack/nova/tree/master/nova/virt/hyperv and https://github.com/openstack/compute-hyperv/ ? | |
| 15:28:39 | melwitt | bauzas: I don't really but lpetrut explains the differences in the patch comment and etherpad. the in tree driver doesn't use os-assisted-volume-snapshots but the out of tree driver does, which is just one example | |
| 15:28:39 | melwitt | bauzas: I don't really but lpetrut explains the differences in the patch comment and etherpad. the in tree driver doesn't use os-assisted-volume-snapshots but the out of tree driver does, which is just one example | |
| 15:28:56 | bauzas | melwitt: okay, then I'll fence the patch above | |
| 15:28:56 | bauzas | melwitt: okay, then I'll fence the patch above | |
| 15:31:23 | melwitt | I kind of wish we could just remove in tree drivers in these cases where "no one is using it", seems pointless to have it in the code | |
| 15:31:23 | melwitt | I kind of wish we could just remove in tree drivers in these cases where "no one is using it", seems pointless to have it in the code | |
| 15:33:19 | lyarwood | agreed | |
| 15:33:19 | lyarwood | agreed | |
| 15:33:25 | bauzas | that's a reasonable concern and we should somehow understand what are the benefits of keeping such code | |
| 15:33:25 | bauzas | that's a reasonable concern and we should somehow understand what are the benefits of keeping such code | |
| 15:34:44 | bauzas | looking at the compute-hyperv repo, this sounds a fork | |
| 15:34:44 | bauzas | looking at the compute-hyperv repo, this sounds a fork | |
| 16:10:07 | artom | sean-k-mooney, so for my own education - if the MTU is going down, telling the guest OS via some means (DHCP?) is enough, no? Because incoming packets will presumably have the new smaller MTU, and so will "fit" on the tap device. So the guest just needs to know to reduce the size of what it sends. | |
| 16:10:07 | artom | sean-k-mooney, so for my own education - if the MTU is going down, telling the guest OS via some means (DHCP?) is enough, no? Because incoming packets will presumably have the new smaller MTU, and so will "fit" on the tap device. So the guest just needs to know to reduce the size of what it sends. | |
| 16:10:45 | artom | The problem comes if the MTU goes up. In that case, the tap device does need to have its MTU increased, to accommodate the larger incoming packets. | |
| 16:10:46 | artom | The problem comes if the MTU goes up. In that case, the tap device does need to have its MTU increased, to accommodate the larger incoming packets. | |
| 16:13:37 | sean-k-mooney | artom: it will be eventually | |
| 16:13:37 | sean-k-mooney | artom: it will be eventually | |
| 16:13:41 | sean-k-mooney | artom: but we already do this | |
| 16:13:41 | sean-k-mooney | artom: but we already do this | |
| 16:14:04 | sean-k-mooney | artom: neutron advertises the mtu to the guest in dhcp for quite a long time | |
| 16:14:04 | sean-k-mooney | artom: neutron advertises the mtu to the guest in dhcp for quite a long time | |
| 16:14:17 | sean-k-mooney | and it will update the value when you update it in the api | |
| 16:14:17 | sean-k-mooney | and it will update the value when you update it in the api | |
| 16:14:38 | sean-k-mooney | but the guest wont ask for a dhcp update until half its remaining lease is avaible | |
| 16:14:38 | sean-k-mooney | but the guest wont ask for a dhcp update until half its remaining lease is avaible | |
| 16:14:50 | sean-k-mooney | a normal leas is between 1-7 days | |
| 16:14:50 | sean-k-mooney | a normal leas is between 1-7 days | |
| 16:15:04 | artom | Ah, and there's no "gratuitous DHCP" | |
| 16:15:04 | sean-k-mooney | so it would be multiple days typeicaly until it was informed | |
| 16:15:04 | artom | Ah, and there's no "gratuitous DHCP" | |
| 16:15:04 | sean-k-mooney | so it would be multiple days typeicaly until it was informed | |