Earlier  
Posted Nick Remark
#openstack-nova - 2021-04-28
08:39:35 lyarwood gibi: https://review.opendev.org/c/openstack/devstack/+/788429 should fix all jobs
08:39:35 lyarwood gibi: https://review.opendev.org/c/openstack/devstack/+/788429 should fix all jobs
08:45:39 gibi does that ^^ superseeds https://review.opendev.org/c/openstack/nova/+/788425 ?
08:45:39 gibi does that ^^ superseeds https://review.opendev.org/c/openstack/nova/+/788425 ?
08:47:18 lyarwood gibi: well I've posted three changes in all, one that fixes just nova-grenade-multinode as it currently is, one that fixes nova-grenade-multinode by moving to the zuulv3 based jobs and a devstack change to fix all bionic based jobs
08:47:18 lyarwood gibi: well I've posted three changes in all, one that fixes just nova-grenade-multinode as it currently is, one that fixes nova-grenade-multinode by moving to the zuulv3 based jobs and a devstack change to fix all bionic based jobs
08:47:40 lyarwood gibi: https://review.opendev.org/c/openstack/nova/+/788425 is something we can land quickly IMHO
08:47:41 lyarwood gibi: https://review.opendev.org/c/openstack/nova/+/788425 is something we can land quickly IMHO
08:47:41 gibi I've just approved the zuul v3 move
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?

Earlier   Later