Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-22
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
10:36:43 bauzas gibi: context ?
10:37:43 gibi bauzas: we have a bug in neutron that creates a slightly wrong RP tree for qos
10:38:16 bauzas gibi: ahah
10:38:18 gibi the expected tree would be computeRP <- neutron agent RP <- deviceRP
10:38:35 gibi but after a bugfix in Ussuri it was changed to
10:38:38 bauzas gibi: related to the ML thread I saw ?
10:39:03 gibi computeRP <- neutron agent RP
10:39:06 gibi computeRP <- device RP
10:39:22 bauzas I see
10:39:31 gibi bauzas: which thread? We just figured this problem out yesterday
10:39:35 bauzas sec
10:39:53 gibi it does not cuase any scheduling issue at the momemnt, this is why it was hidden so long
10:40:06 bauzas title is '[ops] Bandwidth problem on computes'
10:40:20 gibi bauzas: nope, that is some physical bandwidht issue
10:40:28 bauzas ah yeah, just looked
10:40:54 gibi so the above bug does not case any issue toady as the agent RP is basically unused
10:41:20 gibi but I have a request to start tracking OVS packet processing capacity as a resource
10:41:45 gibi and as today the ovs agent has a 1-1 relationship with the ovs agent, the ovs agent RP would be a good place for that new resource
10:42:01 bauzas okay I see the problem
10:42:05 lucasagomes hi, can someone please take a look at https://review.opendev.org/c/openstack/nova/+/776419, https://review.opendev.org/c/openstack/nova/+/776944 and https://review.opendev.org/c/openstack/nova/+/776934 ?
10:42:06 gibi I mean the ovs agent has 1-1 relationship with OVS itself
10:42:22 gibi bauzas: so first I would like to fix the bug
10:42:25 lucasagomes These are small patches that will prevent the nova gate from breaking when we change the default network backend in DevStack to OVN next cycle
10:42:29 gibi and then introduce new resources
10:43:04 gibi lucasagomes: I don't expect that these patches will be merged before the RC1 and the stable/wallaby is cut.
10:43:44 lucasagomes gibi, ah fair enough ok
10:44:02 gibi lucasagomes: but kick me after the cut and I will find somebody to review them
10:44:17 gibi bauzas: so one way to fix it is to re-parent the device RP
10:44:20 lucasagomes gibi, that sounds good, thanks much!
10:44:30 gibi bauzas: under the agent RP as it was before Ussuri
10:44:58 gibi bauzas: anyhow I will look into the reshape way now
10:45:58 gibi that is a good tip
10:46:50 gibi s/tip/suggestion/
10:49:34 gibi bauzas: hm, so /reshape moves inventory and allocation between RPs but it does not move RPs between parents
10:50:44 gibi so I could create a new device RP under the agent and move the inventory and the allocations from the old device RP to the new device RP and then delete the old device RP

Earlier   Later