| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 08:56:06 | opendevreview | Lee Yarwood proposed openstack/nova master: zuul: Skip test_live_migration_with_trunk until bug #1933954 is fixed https://review.opendev.org/c/openstack/nova/+/798580 | |
| 09:31:48 | stephenfin | sean-k-mooney: gibi: bauzas: When you're all around, I'd like to pick up discussion on that availability zone issue again (I got stuck in meetings after lunch yesterday) | |
| 09:32:24 | bauzas | stephenfin: I'm working on some A100 vGPU test... :( | |
| 09:32:38 | bauzas | urgent query from some PM | |
| 09:32:57 | stephenfin | ah, no worries, I guess I can keep it to the Gerrit review and let you respond async | |
| 09:33:28 | stephenfin | tl;dr: I still have concerns about recording null or the default AZ when the host doesn't belong to the availability zone | |
| 09:35:23 | stephenfin | I'd be okay with overwriting the requested AZ with the hosts AZ (with a warning) if we insist on not blocking the request | |
| 09:37:06 | lyarwood | https://bugs.launchpad.net/nova/+bug/1933954 and https://bugs.launchpad.net/nova/+bug/1933958 smell related to me if anyone with more neutron context has time to review | |
| 09:39:39 | bauzas | stephenfin: that's probably why we should only record None | |
| 09:39:48 | bauzas | and not the default AZ | |
| 09:40:09 | bauzas | stephenfin: so, letting the instance to be movable between AZs | |
| 09:41:12 | bauzas | stephenfin: if operators want the instance to *not* be movable between AZs, they should use both --az and --host | |
| 09:46:23 | bauzas | stephenfin: replied on PS1 https://review.opendev.org/c/openstack/nova/+/798145 | |
| 09:48:27 | rohit02 | hi team on any openstack ussuri we are getting error while launching multiattach volume booted instance on horizon"Multiattach volumes are only supported starting with compute API version 2.60. (HTTP 400) (Request-ID: req-fd275b1c-c827-460f-9005-ff9f3d02dbb6)" | |
| 09:50:32 | rohit02 | is a known issue for multiattach volume type for horizon? is there any fix for this issue | |
| 09:53:44 | lyarwood | Odd, no idea why Horizon wouldn't be using 2.latest tbh | |
| 09:54:01 | lyarwood | is it configurable in Horizon? | |
| 09:57:03 | stephenfin | lyarwood: Yeah, they look related. Looking at the logs for the first one (https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_8f7/771362/28/check/nova-live-migration/8f76ccd/compute1/logs/screen-n-cpu.txt) I see: | |
| 09:57:12 | stephenfin | "Neutron is not new enough to perform early destination host port binding activation. Port bindings will be updated later." | |
| 09:58:01 | stephenfin | which only happens if neutron doesn't support port bindings, apparently https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2860-L2868 | |
| 09:58:43 | lyarwood | cool cool, I don't see anything obvious in nova or neutron that might be causing this | |
| 09:58:57 | lyarwood | guess it might be in devstack or tempest (for the job definitions) | |
| 10:00:10 | stephenfin | I'm looking at recent devstack changes as we speak | |
| 10:00:15 | stephenfin | I asked on #openstack-neutron too | |
| 10:01:52 | lyarwood | ta | |
| 10:03:12 | stephenfin | Merge "[ML2] Change way how list of supported API extensions is made" | |
| 10:03:14 | stephenfin | that looks relevant | |
| 10:03:17 | stephenfin | (from neutron) | |
| 10:05:50 | lyarwood | gah I was looking at author and not the commit date | |
| 10:07:36 | stephenfin | git config :q | |
| 10:07:39 | stephenfin | whoops | |
| 10:08:38 | stephenfin | git config format.pretty fuller # <-- if you don't have it, very helpful | |
| 10:08:53 | lyarwood | wonder if that works with tig | |
| 10:09:57 | lyarwood | nope, nvm I'll just engage my brain next time | |
| 10:10:20 | stephenfin | ||
| 10:10:23 | stephenfin | lyarwood: fyi ^ | |
| 10:10:34 | stephenfin | (from #openstack-neutron) | |
| 10:10:40 | lyarwood | Coolio | |
| 10:15:28 | opendevreview | Stephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix https://review.opendev.org/c/openstack/nova/+/798635 | |
| 10:18:21 | opendevreview | Stephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix https://review.opendev.org/c/openstack/nova/+/798635 | |
| 10:31:50 | kashyap | lyarwood: Hi, is this soft-lockup w/ CirrOS consistently reproducible? - https://bugs.launchpad.net/nova/+bug/1931702 | |
| 10:33:00 | lyarwood | kashyap: hard to say, I had to hack dumping the console log into a few runs of the job before we disabled certain tests that always failed, I've not had time to rerun things with that change reverted yet | |
| 10:34:16 | kashyap | Hm; I saw your comment on the console log. | |
| 10:34:45 | lyarwood | kashyap: https://review.opendev.org/c/openstack/tempest/+/794757 and https://review.opendev.org/c/openstack/nova/+/795997 FWIW | |
| 10:38:07 | kashyap | lyarwood: Thanks for the rework; and the skip makes sense for now. To guess a non-OpenStack reproducer from the test: | |
| 10:39:13 | kashyap | lyarwood: Live-migrating a guest, its disk, with an additional file-based disk should do it? | |
| 10:39:34 | lyarwood | kashyap: yeah pretty much | |
| 10:40:02 | kashyap | lyarwood: Okay; thanks. I can also ask the virt QE to add a test to this effect to this suite. As this is a common path for OpenStack | |
| 11:13:44 | gibi | kashyap: do you want to talk about https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device on the todays Nova meeting? | |
| 11:23:34 | kashyap | gibi: Oh, hi. Yes, that'd be good | |
| 11:23:50 | gibi | then I will add it to the agenda | |
| 11:23:51 | kashyap | gibi: Thanks for priming my memory | |
| 11:26:19 | gibi | no problem | |
| 11:43:20 | gibi | stephenfin: I'm here until the top of the hour to talk about the availability zone check. Alternatively I'm here from 15:30 CEST till the nova meeting | |
| 11:47:28 | gibi | stephenfin: bauzas replyed in the review and I think that was how I understood the the original agreement. so --az az:host should be translated to an internal behavior to match the --host host behavior and log a warning if that host is not in the az | |
| 11:49:27 | kashyap | gibi: Afraid, I might not be there for the entire meeting, as I have to run for an errand; I see it's 18:00 CET (1600 UTC) | |
| 11:50:11 | gibi | kashyap: I can move the topic a earlier in the agend, what is your cut of time_ | |
| 11:50:14 | gibi | ? | |
| 11:50:46 | kashyap | I can be around the first 20 mins | |
| 11:50:53 | kashyap | Thank you, as usual for adjusting. I feel guilty :D | |
| 11:51:30 | gibi | kashyap: OK, I will move it. Don't worry | |
| 11:52:58 | kashyap | Thx! | |
| 12:53:03 | bauzas | gibi: again, even if we do the same, the main difference between the az hack and the --host value is that for the former, we don't verify the AZ | |
| 12:53:44 | gibi | bauzas: but for the --host we also not verify any az as az was not even provided | |
| 12:53:45 | bauzas | that's why I would like to continue to not verify it, but saying that the instance couldn't be stuck to a specific AZ | |
| 12:54:01 | bauzas | gibi: ah, correct indeed | |
| 12:54:03 | gibi | that work sof me | |
| 12:54:08 | gibi | works for me | |
| 12:54:13 | bauzas | kk | |
| 12:54:56 | gibi | so in --az my-az:host we dont enforce my-az, we simply replace that to whathever internal data that represents --host host only | |
| 12:55:21 | gibi | I don't want to say "ignore az" as I'd like to have a warning that the az is ignored | |
| 12:55:55 | gibi | question: do we only ignore the az if the host is not in the az, or we ignore it even if the host is in the az? | |
| 13:06:12 | sean-k-mooney | gibi: https://review.opendev.org/c/openstack/nova/+/797428/2 has finally passed check so im +1 on it and the preceeding patch if we want to move those forward now | |
| 13:06:36 | sean-k-mooney | oh your +2 on that bauzas ^ | |
| 13:06:53 | gibi | yepp I'm OK | |
| 13:07:04 | sean-k-mooney | bauzas: its stephens fixs for my port delegation patch | |
| 13:07:25 | bauzas | sean-k-mooney: ok, I can take a look | |
| 13:07:31 | bauzas | gibi: I haven't seen your question, looking | |
| 13:07:45 | sean-k-mooney | gibi: thanks for reviewing those | |
| 13:08:11 | bauzas | gibi: by saying --az foo:host, we make the instance movable between AZs | |
| 13:08:25 | bauzas | gibi: so, the instance will land on host1 which can be on az1 | |
| 13:08:47 | bauzas | gibi: but eventually, the instance could be moved to another host in az2 as the requested AZ eventually is "None" | |
| 13:08:57 | gibi | bauzas: so if --az foo:host and host in foo then we still not pin the instance to foo az toda? | |
| 13:09:00 | gibi | y | |
| 13:09:22 | bauzas | gibi: today, we stick to foo | |
| 13:09:33 | bauzas | gibi: even if host isn't in foo | |
| 13:09:56 | bauzas | tomorrow, we'll stick to nothing and leave the instance be in any AZ | |
| 13:10:25 | bauzas | if host is in 'bar' AZ, fine | |
| 13:10:34 | gibi | bauzas: ack, this works for me | |
| 13:10:41 | sean-k-mooney | the alternitive being stick to the az that host is in, reject the request or keep the current behavior | |
| 13:10:57 | sean-k-mooney | i think im ok with what bauzas is suggesting too | |
| 13:11:14 | bauzas | and like I said, if the operator wants to land on host and stick to foo, they can say --host host and --az foo | |
| 13:11:27 | bauzas | then, they'll get NoValidHosts | |
| 13:11:47 | bauzas | sean-k-mooney: I don't like the alternative as I don't wanna verify the AZ by the API | |
| 13:11:58 | bauzas | since the AZFilter can be disabled | |
| 13:12:12 | sean-k-mooney | its not related to the az filter | |
| 13:12:14 | bauzas | and I know some ops that use forced_hosts hack but don't run AZFilter | |
| 13:12:31 | sean-k-mooney | instance hav az without that | |
| 13:12:46 | bauzas | we only enforce AZs by the filter | |
| 13:12:56 | bauzas | or by placement | |