| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-28 | |||
| 08:47:41 | gibi | I've just approved the zuul v3 move | |
| 08:47:41 | lyarwood | gibi: https://review.opendev.org/c/openstack/nova/+/788425 is something we can land quickly IMHO | |
| 08:47:42 | gibi | I've just approved the zuul v3 move | |
| 08:47:47 | lyarwood | ah there we go then | |
| 08:47:47 | lyarwood | ah there we go then | |
| 08:47:58 | lyarwood | I'll drop https://review.opendev.org/c/openstack/nova/+/788425 | |
| 08:47:59 | lyarwood | I'll drop https://review.opendev.org/c/openstack/nova/+/788425 | |
| 08:48:01 | gibi | Ok | |
| 08:48:01 | gibi | Ok | |
| 08:48:29 | gibi | thanks | |
| 08:48:48 | lyarwood | the zuulv3 change should also move our grenade testing to focal to focal finally | |
| 08:48:48 | lyarwood | the zuulv3 change should also move our grenade testing to focal to focal finally | |
| 08:48:55 | lyarwood | we dropped bionic back in ussuri | |
| 08:48:56 | lyarwood | we dropped bionic back in ussuri | |
| 09:11:09 | sean-k-mooney | does anyone know why we have an os_type column in the instances table | |
| 09:11:10 | sean-k-mooney | does anyone know why we have an os_type column in the instances table | |
| 09:12:03 | sean-k-mooney | as far as i can tell we always use the os_type image metadata property when generating xmls or schduling | |
| 09:12:04 | sean-k-mooney | as far as i can tell we always use the os_type image metadata property when generating xmls or schduling | |
| 09:12:11 | sean-k-mooney | not an os_type form the instance | |
| 09:12:12 | sean-k-mooney | not an os_type form the instance | |
| 09:23:04 | stephenfin | bauzas: Are you okay with me addressing your nits and then reviewing https://review.opendev.org/c/openstack/nova/+/695012 myself? I think the bulk of the change will stay the same | |
| 09:23:04 | stephenfin | bauzas: Are you okay with me addressing your nits and then reviewing https://review.opendev.org/c/openstack/nova/+/695012 myself? I think the bulk of the change will stay the same | |
| 09:23:47 | bauzas | stephenfin: woah, long story here, I can't remember the context but sure | |
| 09:23:47 | bauzas | stephenfin: woah, long story here, I can't remember the context but sure | |
| 09:24:42 | sean-k-mooney | we really should try and get that serise merged | |
| 09:24:42 | sean-k-mooney | we really should try and get that serise merged | |
| 09:26:45 | sean-k-mooney | hum i wonder why i never left any review comments on that unless its a different seriese form mark | |
| 09:26:45 | sean-k-mooney | hum i wonder why i never left any review comments on that unless its a different seriese form mark | |
| 09:29:56 | sean-k-mooney | oh i was thinking of https://review.opendev.org/c/openstack/nova/+/710848 https://review.opendev.org/c/openstack/nova/+/710847 and https://review.opendev.org/c/openstack/nova/+/760354 | |
| 09:29:56 | sean-k-mooney | oh i was thinking of https://review.opendev.org/c/openstack/nova/+/710848 https://review.opendev.org/c/openstack/nova/+/710847 and https://review.opendev.org/c/openstack/nova/+/760354 | |
| 09:50:38 | stephenfin | gibi: Could I get you to review the small diff on https://review.opendev.org/c/openstack/nova/+/676209 yet again, please? /o\ | |
| 09:50:38 | stephenfin | gibi: Could I get you to review the small diff on https://review.opendev.org/c/openstack/nova/+/676209 yet again, please? /o\ | |
| 09:51:01 | stephenfin | lyarwood: Any chance you'd be able to slog through that so I can finally close it out? I genuinely think it's a useful addition | |
| 09:51:01 | stephenfin | lyarwood: Any chance you'd be able to slog through that so I can finally close it out? I genuinely think it's a useful addition | |
| 09:58:12 | lyarwood | stephenfin: yup I'll queue it up for later today if that's okay | |
| 09:58:12 | lyarwood | stephenfin: yup I'll queue it up for later today if that's okay | |
| 09:58:22 | stephenfin | wfm. Thanks | |
| 09:58:22 | stephenfin | wfm. Thanks | |
| 09:58:32 | lyarwood | stephenfin: and I'll likely ask for the same later in the cycle for the block layer | |
| 09:58:33 | lyarwood | stephenfin: and I'll likely ask for the same later in the cycle for the block layer | |
| 09:58:39 | stephenfin | fair :) | |
| 09:58:39 | stephenfin | fair :) | |
| 10:12:14 | gibi | stephenfin: I will check it after my lunch | |
| 10:12:14 | gibi | stephenfin: I will check it after my lunch | |
| 10:24:12 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788467 | |
| 10:24:47 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788468 | |
| 10:24:47 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788468 | |
| 10:26:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788469 | |
| 10:26:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: libvirt: Ignore device already in the process of unplug errors https://review.opendev.org/c/openstack/nova/+/788469 | |
| 10:41:04 | sean-k-mooney | stephenfin: +1 on the first patch for nova.pci | |
| 10:41:04 | sean-k-mooney | stephenfin: +1 on the first patch for nova.pci | |
| 10:41:15 | stephenfin | thanks :) | |
| 10:41:15 | stephenfin | thanks :) | |
| 10:41:28 | sean-k-mooney | stephenfin: i have 2 other review i want to complte first then ill see if i can get back to the rest | |
| 10:41:28 | sean-k-mooney | stephenfin: i have 2 other review i want to complte first then ill see if i can get back to the rest | |
| 10:45:02 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |
| 11:00:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Testing with sqlalchemy 1.4 https://review.opendev.org/c/openstack/nova/+/788471 | |
| 11:00:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Testing with sqlalchemy 1.4 https://review.opendev.org/c/openstack/nova/+/788471 | |
| 11:01:13 | gibi | fyi we are expected failures and therefore work here ^^ | |
| 11:01:13 | gibi | fyi we are expected failures and therefore work here ^^ | |
| 11:01:21 | gibi | s/expected/expecting/ | |
| 11:01:22 | gibi | s/expected/expecting/ | |
| 11:11:22 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509 | |
| 11:11:33 | gibi | reported https://bugs.launchpad.net/nova/+bug/1926426 to track the work | |
| 11:11:35 | openstack | Launchpad bug 1926426 in OpenStack Compute (nova) "Nova is not compatible with sqlalchemy 1.4" [High,Triaged] | |
| 11:11:35 | gibi | reported https://bugs.launchpad.net/nova/+bug/1926426 to track the work | |
| 11:11:35 | openstack | Launchpad bug 1926426 in OpenStack Compute (nova) "Nova is not compatible with sqlalchemy 1.4" [High,Triaged] | |
| 11:13:17 | sean-k-mooney | is the issue the test or the production code? | |
| 11:13:17 | sean-k-mooney | is the issue the test or the production code? | |
| 11:13:56 | sean-k-mooney | looks like maybe both | |
| 11:13:56 | sean-k-mooney | looks like maybe both | |
| 11:14:02 | sean-k-mooney | have we capped it in UC | |
| 11:14:02 | sean-k-mooney | have we capped it in UC | |
| 11:15:24 | sean-k-mooney | ah we had to 1.3.23 previously | |
| 11:15:24 | sean-k-mooney | ah we had to 1.3.23 previously | |
| 11:15:50 | gibi | it is a test coming from a proposed UC bump | |
| 11:15:50 | gibi | it is a test coming from a proposed UC bump | |
| 11:16:07 | gibi | so far we see one oslo.db issue but we also seem to have some nova specific failure modes as well | |
| 11:16:07 | gibi | so far we see one oslo.db issue but we also seem to have some nova specific failure modes as well | |
| 11:56:26 | gibi | sean-k-mooney: Did I understood the comment from the PTG well about when we need direction aware and when we need direction less pps resource? https://review.opendev.org/c/openstack/neutron-specs/+/785236/3/specs/xena/qos-minimum-guaranteed-packet-rate.rst#266 | |
| 11:56:26 | gibi | sean-k-mooney: Did I understood the comment from the PTG well about when we need direction aware and when we need direction less pps resource? https://review.opendev.org/c/openstack/neutron-specs/+/785236/3/specs/xena/qos-minimum-guaranteed-packet-rate.rst#266 | |
| 11:58:37 | sean-k-mooney | sorry have nto got to your spec yet today but ill take a look at that comment now one sec | |
| 11:58:37 | sean-k-mooney | sorry have nto got to your spec yet today but ill take a look at that comment now one sec | |
| 11:59:41 | sean-k-mooney | gibi: so ya | |
| 11:59:41 | sean-k-mooney | gibi: so ya | |
| 12:00:01 | sean-k-mooney | we can either put the sum of the direct based values in the request | |
| 12:00:01 | sean-k-mooney | we can either put the sum of the direct based values in the request | |
| 12:00:22 | sean-k-mooney | or we can have 3 resources class and just make the user choose the correct policy | |
| 12:00:22 | sean-k-mooney | or we can have 3 resources class and just make the user choose the correct policy | |
| 12:01:46 | sean-k-mooney | i kind of like having 3 reosuce classes PPS_TOTAL, PPS_INGRESS and PPS_EGRESS | |
| 12:01:47 | sean-k-mooney | i kind of like having 3 reosuce classes PPS_TOTAL, PPS_INGRESS and PPS_EGRESS | |
| 12:01:52 | gibi | so then in case of hw offloaded OVS the packet processing bottleneck is not some kind of shared resource (like the CPU in case of normal OVS) but some direction specific hardware resoruce? | |
| 12:01:52 | gibi | so then in case of hw offloaded OVS the packet processing bottleneck is not some kind of shared resource (like the CPU in case of normal OVS) but some direction specific hardware resoruce? | |
| 12:02:37 | gibi | hence we need to track resource inventory per direction separately | |
| 12:02:37 | gibi | hence we need to track resource inventory per direction separately | |
| 12:02:41 | sean-k-mooney | well yes and know. the pcie bandwith is a shared resouce but hardware offloaded ovs use sriov VFs for the dataplane | |
| 12:02:41 | sean-k-mooney | well yes and know. the pcie bandwith is a shared resouce but hardware offloaded ovs use sriov VFs for the dataplane | |
| 12:03:03 | sean-k-mooney | so we can pretend it just sriov in this case | |
| 12:03:03 | sean-k-mooney | so we can pretend it just sriov in this case | |
| 12:03:22 | sean-k-mooney | vdpa is more or less the same in that the parent of the vdpa device atleat today is a VF | |