| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-15 | |||
| 19:54:49 | gmann | mnaser: scope for all the policy rule is 'project' now so enabling the scope is to reject the system scope token at early stage with 403. existing project scope token keep working whether scope is enabled or disabled | |
| 19:55:48 | gmann | but yes, you can keep only new defaults enable which will work fine unless system scoped token is used | |
| 19:56:28 | gmann | with scope disabled system scope token may fail (for project level resources) later on as they do not have project id | |
| 19:58:01 | gmann | I think horizon is using project scoped token (they have not changed it for srabc) so scope enable/disable should not impact there | |
| 19:59:51 | gmann | kolla was the one who were using system scope for nova which is now fixed https://review.opendev.org/c/openstack/kolla-ansible/+/870879 | |
| 20:00:21 | gmann | other than that no body reported if new defaults or scope enable has impacted them | |
| 20:10:46 | mnaser | gmann: oh I see, so as of now, as long as we don’t have custom policies, we should be able to flip it on? | |
| 20:13:11 | gmann | mnaser: yeah | |
| 20:13:38 | mnaser | gmann: ok we’ll flip that and see how it goes! Thank you. | |
| #openstack-nova - 2023-02-16 | |||
| 03:44:53 | opendevreview | Hiroki Narukawa proposed openstack/nova master: libvirt: retry libvirt connection on live_migration_monitor https://review.opendev.org/c/openstack/nova/+/867077 | |
| 08:05:04 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix wrong description about minimum values https://review.opendev.org/c/openstack/nova/+/874061 | |
| 08:52:00 | opendevreview | melanie witt proposed openstack/nova stable/yoga: db: Resolve additional SAWarning warnings https://review.opendev.org/c/openstack/nova/+/874065 | |
| 08:57:49 | opendevreview | melanie witt proposed openstack/nova stable/xena: db: Resolve additional SAWarning warnings https://review.opendev.org/c/openstack/nova/+/874066 | |
| 09:30:20 | opendevreview | melanie witt proposed openstack/nova stable/wallaby: db: Resolve additional SAWarning warnings https://review.opendev.org/c/openstack/nova/+/874069 | |
| 09:31:45 | opendevreview | melanie witt proposed openstack/nova stable/victoria: db: Resolve additional SAWarning warnings https://review.opendev.org/c/openstack/nova/+/874071 | |
| 09:32:37 | opendevreview | melanie witt proposed openstack/nova stable/ussuri: db: Resolve additional SAWarning warnings https://review.opendev.org/c/openstack/nova/+/874072 | |
| 09:45:43 | elodilles | bauzas gibi : i don't know whether you noticed, but os-traits 2.10.0 is in the upper constraints \o/ | |
| 09:49:23 | bauzas | elodilles: clap clap | |
| 09:49:28 | bauzas | thanks for the dedication | |
| 09:50:43 | elodilles | np | |
| 09:52:04 | gibi | thanks folks | |
| 09:52:29 | bauzas | gibi: do we need to modify placement to support those traits ? AFAIR yes | |
| 09:52:35 | gibi | bauzas: yes | |
| 09:52:44 | bauzas | I can work on that | |
| 09:53:00 | gibi | feel free to ping me for review | |
| 09:53:07 | bauzas | (provided I easily find the pattern) | |
| 09:53:22 | gibi | bauzas: I think it is just a bump in requirements.txt nothing more | |
| 09:53:25 | gibi | the rest is automatic | |
| 09:53:47 | bauzas | aren't we checking the number of traits we support ? | |
| 09:53:47 | gibi | placement loads all the trait defs from whathever os-traits lib it founds at startup | |
| 09:53:49 | bauzas | I thought so | |
| 09:53:59 | gibi | I think we fixed that check | |
| 09:55:35 | gibi | https://review.opendev.org/c/openstack/placement/+/851966 | |
| 09:56:55 | bauzas | gibi: great | |
| 10:14:25 | bauzas | gibi: hah, fun, we forgot to bump the reqs for 2.9.0 https://github.com/openstack/placement/blob/master/requirements.txt#L29 | |
| 10:15:02 | bauzas | gibi: but since we don't pin on a release, we should get 2.10 | |
| 10:15:32 | bauzas | so technically, it's more about saying that for 2023.1 Placement will always support those traits are bare min | |
| 10:15:39 | bauzas | as* bare | |
| 10:24:39 | gibi | bauzas: yeah that is still on me to have a limited lower constraint job running on placement and nova to catch these as we only test with upper today | |
| 10:25:05 | gibi | I tried to do that after the last PTG but it was non trivial so I never finished it | |
| 10:25:09 | bauzas | cool, we haven't branched RC1 yet so we're on time | |
| 10:25:31 | bauzas | for the moment, we need to just make sure we document this | |
| 10:27:42 | gibi | I believe more in systems that enforces rules than documentation that we don't read when we should | |
| 10:29:51 | opendevreview | Sylvain Bauza proposed openstack/placement master: Update 2023.1 reqs to support os-traits 2.10 as min version https://review.opendev.org/c/openstack/placement/+/874080 | |
| 10:30:02 | bauzas | we have the PTL docs that I personnally enforce :) | |
| 10:30:44 | bauzas | gibi: sean-k-mooney: time for a placement review https://review.opendev.org/c/openstack/placement/+/874080 | |
| 10:30:57 | gibi | bauzas: +@ | |
| 10:30:58 | gibi | bauzas: +2 | |
| 10:56:46 | bauzas | nova-next is getting me mad | |
| 10:57:26 | bauzas | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_e4a/821228/7/gate/nova-next/e4ab52f/testr_results.html is anthologic | |
| 10:57:37 | bauzas | volume timeouts + guest kernel tainting | |
| 11:02:02 | opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: update description for live_migration_completion_timeout https://review.opendev.org/c/openstack/nova/+/874083 | |
| 12:21:20 | gibi | bauzas: is this with the new cirros version? | |
| 12:23:10 | bauzas | gibi: nope, we haven't merged yet the change | |
| 12:23:41 | bauzas | I haven't verified which cirros image we were having with the test, but I guess it's still 0.5 | |
| 12:24:06 | bauzas | 2023-02-15 20:08:15.854905 | controller | ++ stackrc:source:692 : DEFAULT_IMAGE_NAME=cirros-0.5.2-x86_64-disk 2023-02-15 20:08:15.856966 | controller | ++ stackrc:source:693 : DEFAULT_IMAGE_FILE_NAME=cirros-0.5.2-x86_64-disk.img | |
| 12:24:10 | bauzas | indeed | |
| 12:26:53 | sean-k-mooney | i said this a few days ago but i do think we should look at going to 0.6.x | |
| 12:27:17 | sean-k-mooney | there are a few kernel bugs in the 0.5.2 image that cause ocational kernel panics related to the apic in the guest | |
| 12:27:41 | sean-k-mooney | the 0.6.2 image is built on the ubuntu 22.04 kernel | |
| 12:29:10 | gibi | bauzas: thanks, then I guess yet another guest kernel bug | |
| 12:30:06 | bauzas | sean-k-mooney: I have a change for this | |
| 12:30:17 | bauzas | sec. | |
| 12:30:32 | bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/873934 | |
| 12:30:56 | bauzas | we could also use 0.6.2 if we want, I'm not against | |
| 12:31:08 | sean-k-mooney | i would prefer ot change it in devstack | |
| 12:31:26 | sean-k-mooney | we can do it per job | |
| 12:31:37 | sean-k-mooney | but it would be better to use the same cirror image in all jobs | |
| 12:32:00 | bauzas | sean-k-mooney: but we can test the new cirros image by nova-next and if we see it works, then we could indeed use it for all our jobs | |
| 12:32:15 | bauzas | nova-next is also there for testing new stuff | |
| 12:32:46 | bauzas | I'm just afraid of changing all our jobs by once without correctly testing first | |
| 12:33:01 | sean-k-mooney | i guess but given we have known kernel issue in the 5.2 image nad we have been trying to change it for years i would prefer to do the change in Antilepe if we can | |
| 14:02:40 | opendevreview | Amit Uniyal proposed openstack/nova master: Added a lock_unlock dcorator for instance https://review.opendev.org/c/openstack/nova/+/873648 | |
| 14:21:20 | opendevreview | Amit Uniyal proposed openstack/nova master: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/873648 | |
| 14:42:28 | bauzas | aaaaaand now I see more and more cirros guest segfaulting... https://review.opendev.org/c/openstack/nova/+/821228/7 | |
| 14:42:38 | bauzas | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_da2/821228/7/check/nova-multi-cell/da2689f/job-output.txt | |
| 14:44:02 | opendevreview | Takashi Natsume proposed openstack/nova master: doc: mark the max microversion for 2023.1 Antelope https://review.opendev.org/c/openstack/nova/+/874103 | |
| 14:50:30 | dansmith | bauzas: where does that scenario:dhcp_client thing come in? | |
| 14:50:56 | bauzas | dansmith: https://review.opendev.org/c/openstack/nova/+/873934 | |
| 14:51:06 | bauzas | dansmith: and https://launchpad.net/bugs/2006467 | |
| 14:51:09 | dansmith | bauzas: right, what does scenario:dhcp_client affect | |
| 14:51:39 | dansmith | does that end up with cirros behaving differently? or does it make tempest do something inside the guest? | |
| 14:51:45 | bauzas | dansmith: ralonsoh told me to use that way b/c of https://review.opendev.org/c/openstack/neutron/+/871272/1/zuul.d/tempest-multinode.yaml | |
| 14:52:02 | bauzas | and I shamelessly copy/pasteed | |
| 14:52:46 | ralonsoh | this is the dhcp client used in cirros 0.6.1 | |
| 14:53:19 | ralonsoh | more info here: https://review.opendev.org/c/openstack/neutron/+/871272 | |
| 14:53:28 | ralonsoh | (in the commit message) | |
| 14:53:55 | dansmith | ralonsoh: but if the cirros client just uses it, what does the tempest config change? | |
| 14:54:39 | ralonsoh | dansmith, https://review.opendev.org/c/openstack/tempest/+/871270/2/tempest/common/utils/linux/remote_client.py | |
| 14:54:49 | ralonsoh | we choose what is the VM dhcp client | |
| 14:55:11 | ralonsoh | --> https://review.opendev.org/c/openstack/tempest/+/871270/2/tempest/config.py | |
| 14:55:21 | dansmith | ralonsoh: that's just for a manual renew, but doesn't affect how the guest works on first boot.. is that what you mean? | |
| 14:55:50 | ralonsoh | dansmith, no, that should not affect how the VM boots | |
| 14:56:06 | ralonsoh | the OS will use the exiting dhcp client | |
| 14:56:12 | dansmith | ralonsoh: gotcha okay, so I guess most of the issues I see getting an IP seem to be related to initial boot | |
| 14:56:17 | ralonsoh | right | |
| 14:56:38 | dansmith | okay cool, just making sure I understand | |
| 15:05:14 | bauzas | ralonsoh: and to clarify, cirros-0.6.x switched its dhch client to dhcpcd ? | |
| 15:05:25 | ralonsoh | yes | |
| 15:06:20 | bauzas | ack | |