| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-23 | |||
| 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 | |
| 16:15:14 | sean-k-mooney | artom: not that im aware of | |
| 16:15:14 | sean-k-mooney | artom: not that im aware of | |
| 16:15:19 | sean-k-mooney | brb getting a drink | |
| 16:15:19 | sean-k-mooney | brb getting a drink | |
| 16:17:19 | artom | "There is a FORCERENEW message that your DHCP server can issue to clients: | |
| 16:17:19 | artom | https://www.ietf.org/rfc/rfc3203.txt | |
| 16:17:19 | artom | Your clients have to support this mechanism, of course." | |
| 16:17:19 | artom | "There is a FORCERENEW message that your DHCP server can issue to clients: | |
| 16:17:19 | artom | https://www.ietf.org/rfc/rfc3203.txt | |
| 16:17:19 | artom | Your clients have to support this mechanism, of course." | |
| 16:17:24 | artom | https://networkengineering.stackexchange.com/questions/25618/dhcp-option-26-mtu-queries | |
| 16:17:24 | artom | https://networkengineering.stackexchange.com/questions/25618/dhcp-option-26-mtu-queries | |
| 16:22:51 | artom | sean-k-mooney, err, the query string is encrypted in SSL | |
| 16:22:51 | artom | sean-k-mooney, err, the query string is encrypted in SSL | |
| 16:23:04 | artom | The host isn't for SNI | |
| 16:23:04 | artom | The host isn't for SNI | |
| 16:23:10 | artom | But the query stirng is | |
| 16:23:10 | artom | But the query stirng is | |
| 16:30:10 | sean-k-mooney | oh ok | |