| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-22 | |||
| 21:25:39 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type | |
| 21:25:59 | sean-k-mooney | yep so add x86_64=pc-i440fx-3.1 | |
| 21:26:03 | rouk | ill get that tested after some food, been at this issue most of the day, heh. | |
| 21:26:55 | rouk | thanks for all the help, even though its not nova's fault, at least the knowledge that this dumb editing can happen from qemu means nova can defend against it. | |
| 21:27:31 | sean-k-mooney | ya. if using the version machine type fixes it then great | |
| 21:27:52 | rouk | maybe that needs to be a default thing thats recommended to set, idk | |
| 21:27:53 | sean-k-mooney | that would at least give use time to think about what to do in nova if anything in the futrue | |
| 21:28:06 | sean-k-mooney | well there are two camps | |
| 21:28:17 | sean-k-mooney | one camp is alwasy uses the versioned machine type | |
| 21:28:29 | sean-k-mooney | and ooo/ redhat openstack does this by default | |
| 21:28:42 | sean-k-mooney | the other camp is alwasy use the latest one | |
| 21:28:55 | sean-k-mooney | so that you get the latest fixes/abi | |
| 21:29:02 | rouk | sure, that works great till qemu screws you | |
| 21:29:19 | rouk | with machine type though, we cant really move to the new instructions well | |
| 21:29:46 | rouk | the xml change would at least persist in the vm config and be fixed on reboot. | |
| 21:30:07 | rouk | version, we just delay till nova can handle it, i guess. | |
| 21:30:17 | rouk | not sure which is better. | |
| 21:30:29 | sean-k-mooney | https://github.com/qemu/qemu/blob/c40ae5a3ee387b13116948cbfe7824f03311db7e/hw/i386/pc_piix.c#L510-L525 | |
| 21:30:32 | sean-k-mooney | there we go | |
| 21:31:07 | sean-k-mooney | so yes those are the version machine type defintions | |
| 21:31:15 | rouk | is there any way to make nova migrate between versions on reboot? | |
| 21:31:31 | rouk | or will i need to use a custom model to do that | |
| 21:31:47 | sean-k-mooney | am nova used too but we now wont | |
| 21:32:06 | rouk | so i guess the custom model is better | |
| 21:32:20 | rouk | at least then i can get everyone to move organically next time they reboot without breaking migrations | |
| 21:32:37 | sean-k-mooney | rouk: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/libvirt-stash-instance-machine-type.html | |
| 21:32:37 | rouk | even if its a dirtier fix | |
| 21:33:09 | sean-k-mooney | well no so on ussuri you could set the machine type explcitly | |
| 21:33:13 | sean-k-mooney | migrate all teh vms | |
| 21:33:30 | sean-k-mooney | then set it back to pc which is the default or leave it unset | |
| 21:33:36 | sean-k-mooney | then they would update on hard reboot | |
| 21:33:46 | rouk | but their migrations will break. | |
| 21:33:59 | rouk | or once its migrated once, it will stick in the config. | |
| 21:34:01 | sean-k-mooney | not unless this happens again | |
| 21:34:19 | rouk | hmm, i guess thats an okay upgrade plan | |
| 21:34:27 | rouk | as long as im not stranded on a setting forever. | |
| 21:34:37 | sean-k-mooney | so what the new spec say | |
| 21:34:54 | sean-k-mooney | is going forward we will recored the machinve type a vm boots with the first time | |
| 21:34:58 | sean-k-mooney | and it will have that forever | |
| 21:35:00 | sean-k-mooney | unless | |
| 21:35:23 | sean-k-mooney | you use the new nova-manage update_machine_type | |
| 21:35:27 | sean-k-mooney | command to change it | |
| 21:35:51 | sean-k-mooney | rouk: before that we would use what ever was in the config when generting the xml | |
| 21:36:30 | sean-k-mooney | if unset it would default to pc | |
| 21:37:41 | sean-k-mooney | anyway i need to grab food too | |
| 21:37:59 | sean-k-mooney | hopefully that hels and you can use a machine-type or update the cpu model for now | |
| 21:38:47 | sean-k-mooney | the reason you hit this issue is 1 you are not using a version machine type today and 2 qemu backported that abi break | |
| 22:27:07 | rouk | sean-k-mooney: with the option set, still breaks. | |
| 22:27:13 | rouk | does it not take effect on migrate? | |
| 22:27:23 | rouk | hw_machine_type = x86_64=pc-i440fx-3.1 | |
| 22:37:18 | rouk | ah, the vm got the default machine='pc-i440fx-4.2' from before. | |
| 22:40:55 | rouk | will it be honored if i change the xml? hmm | |
| 23:03:35 | rouk | nah, so i guess the custom model is the only way. | |
| 23:32:10 | rouk | sean-k-mooney: <feature policy='disable' name='npt'/> in the destination epyc-ibpb.xml also doesnt work. | |
| 23:32:19 | rouk | dont think anything can be disabled here? | |
| 23:53:18 | rouk | but yes, qemu moved from 3.1 to 4.2 in a single release version on ubuntu cloud repo | |
| 23:53:24 | rouk | guess i can rollback | |
| #openstack-nova - 2021-03-23 | |||
| 00:08:46 | rouk | old qemu - > migrate to 3.1 machine type - > upgrade qemu - > update machine type - > slowly let people trickle over is the migration plan till nova can handle this, i guess. | |
| 02:30:36 | openstackgerrit | xinyu wang proposed openstack/nova-specs master: add instance join/leave server group https://review.opendev.org/c/openstack/nova-specs/+/782353 | |
| 03:25:33 | openstackgerrit | xinyu wang proposed openstack/nova master: join/leave server group https://review.opendev.org/c/openstack/nova/+/782356 | |
| 03:35:16 | openstackgerrit | xinyu wang proposed openstack/nova master: join/leave server group https://review.opendev.org/c/openstack/nova/+/782356 | |
| 06:30:03 | openstackgerrit | Josephine Seifert proposed openstack/nova stable/ussuri: Add config parameter 'live_migration_scheme' to live migration with tls guide https://review.opendev.org/c/openstack/nova/+/782126 | |
| 08:14:39 | Luzi | gibi, elod, lyarwood: the next backport (part 2 of 4) https://review.opendev.org/c/openstack/nova/+/782126 | |
| 08:18:18 | kinpaa12389 | Hi, | |
| 08:18:19 | kinpaa12389 | Due to token expiry value in keystone.conf, glanceclient receive 401 error. How do I debug this 401 error in keystone ? | |
| 08:18:19 | kinpaa12389 | I am trying to create snapshot from server. In this operation, I have added expiration value in keystone.conf and time.sleep() in snapshot() | |
| 08:18:20 | kinpaa12389 | keys=root, access, warnings, keystone, cc, radius, keystonemiddleware, keystoneauth, oslo_messaging, ldap, amqp, amqplib, sqlalchemy | |
| 08:18:20 | kinpaa12389 | Enabled all logs of keystone, still not able to see place from where this error is thrown to glanceclient ? | |
| 08:18:21 | kinpaa12389 | ~ | |
| 08:18:21 | kinpaa12389 | above are keys in /etc/keystone/logging.conf | |
| 08:38:04 | lyarwood | Luzi: LGTM but could you cherry-pick -x $commit_from_stable_victoria https://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes | |
| 08:38:49 | kashyap | Is it the fix to the LM w/ TLS guide? | |
| 08:39:03 | lyarwood | yes | |
| 08:39:03 | kashyap | Ah, yep | |
| 08:39:08 | kashyap | Mornin, folks | |
| 08:39:12 | lyarwood | morning | |
| 08:41:37 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765770 | |
| 08:45:30 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Add regression test for bug #1895696 https://review.opendev.org/c/openstack/nova/+/752487 | |
| 08:45:32 | openstack | bug 1895696 in Cinder "unable to boot instance from encrypted volume created from a glance image of an encrypted volume" [Undecided,New] https://launchpad.net/bugs/1895696 | |
| 08:45:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: compute: Skip cinder_encryption_key_id check when booting from volume https://review.opendev.org/c/openstack/nova/+/752489 | |
| 08:45:33 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Create volume attachment during boot from volume in compute https://review.opendev.org/c/openstack/nova/+/752488 | |
| 08:52:37 | openstackgerrit | Josephine Seifert proposed openstack/nova stable/ussuri: Add config parameter 'live_migration_scheme' to live migration with tls guide https://review.opendev.org/c/openstack/nova/+/782126 | |
| 08:54:05 | Luzi | lyarwood, ^ is this what you meant? | |
| 08:54:17 | lyarwood | yup ack'd thanks | |
| 09:08:38 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: compute: Lock by instance.uuid lock during swap_volume https://review.opendev.org/c/openstack/nova/+/758734 | |
| 09:09:26 | lyarwood | some quick and easy docs changes ahead of rc if anyone has time https://review.opendev.org/c/openstack/nova/+/779479 & https://review.opendev.org/c/openstack/nova/+/779446 | |
| 09:21:18 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Use absolute path during qemu img rebase https://review.opendev.org/c/openstack/nova/+/780790 | |
| 10:28:21 | gibi | does somebody remembers why we forbid reparenting RPs in placement? I think we allow null -> parent_uuid update but we reject parent_uuid -> new_parent_uuid update. I would need local reparenting, moving an RP to another parent within the same PR tree | |
| 10:28:45 | gibi | I can see that moving an RP to one tree to the other could break things in the allocations | |
| 10:34:54 | bauzas | gibi: because it would need some reshape, maybe ? | |
| 10:35:05 | bauzas | :) | |
| 10:35:18 | gibi | bauzas: yeah if there are allocations then moving an RP could invalidate them | |
| 10:35:24 | gibi | in the generic case | |
| 10:35:27 | bauzas | gibi: afair, we only accept to modify the RPs by some reshape method | |
| 10:35:39 | bauzas | like we did for vGPUs and others | |
| 10:36:01 | bauzas | if we modify the parent, then the resources would also be modified | |
| 10:36:04 | gibi | does reshape allows reparenting? | |
| 10:36:10 | bauzas | gibi: yup | |
| 10:36:22 | bauzas | you provide new inventories | |
| 10:36:25 | gibi | hm, then reshape it is | |