| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-23 | |||
| 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 | |
| 10:51:02 | gibi | e | |
| 10:51:02 | gibi | this could work from placement perspectiv | |
| 10:52:44 | gibi | neutron port does store the uuid of the RP the port is allocation from. So that would need to change too | |
| 10:53:48 | bauzas | gibi: you provide a new tree with the reshape API | |
| 10:54:42 | gibi | bauzas: really? I don't see RPs provided in the API | |
| 10:54:50 | gibi | I see inventories and allocations | |
| 11:03:17 | gibi | bauzas: the vgpu reshape also create the pgpu RPs _before_ the placement reshape call https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8414 | |
| 11:05:07 | bauzas | gibi: sure, but we provided back the new provider tree by this method https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8380 | |
| 11:05:33 | bauzas | gibi: so, we provide a new tree and then we look at the allocations | |
| 11:05:43 | bauzas | if there are some of them, then we call the reshape API | |
| 11:06:06 | bauzas | https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8102 | |
| 11:06:29 | bauzas | s/allocs/inventories | |
| 11:08:23 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#proposed-change | |
| 11:08:58 | bauzas | gibi: every 60 secs (by default), the virt driver passes back the provider tree | |
| 11:09:09 | bauzas | so it can change it | |
| 11:09:57 | bauzas | but if the virt driver wants to modify the tree by punting new inventories and allocations from a RP to another one, then it needs to tell placement to move them | |
| 11:10:43 | bauzas | gibi: I can understand your concern, you don't want to move inventories or allocations, but just moving the parent | |
| 11:12:25 | bauzas | but then I guess that the resources would be modified | |
| 11:12:51 | bauzas | gibi: say, for example, with https://docs.openstack.org/placement/latest/user/provider-tree.html#filtering-by-tree | |
| 11:13:11 | bauzas | you would then get different candidates | |
| 11:13:44 | bauzas | that's why we need to be sure that we won't have different resources | |
| 11:14:50 | gibi | sure if I change the structure of the tree then the in_tree a_c queries will change | |
| 11:15:27 | gibi | regardless if I change the tree with reshape or just going in the db and change the parent_uuid of an RP | |