| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-28 | |||
| 22:31:09 | rm_work | nevermind, figured it out, there's a client patch I didn't know about >_< FML | |
| 22:35:45 | clarkb | rm_work: don't leave us hanging. What causes it? | |
| 22:41:40 | rm_work | local client patch where someone did something ... ill advised | |
| 22:41:54 | rm_work | trying to figure out how to untangle it now | |
| 22:45:30 | clarkb | Oh I see what you mean by client patch now. I thought you meant you found the chagne in gerrit taht did it or something | |
| #openstack-nova - 2022-09-29 | |||
| 08:29:10 | songwenping | bauzas: hi, i have some doubt about nova zed highlight, what is the improvement for 'the possibility to rebuild a volume-backed instance'? | |
| 08:32:14 | gibi | songwenping: this is the code we merged to suppot it https://review.opendev.org/q/topic:bp/volume-backed-server-rebuild+status:merged | |
| 08:33:46 | songwenping | is this the API imporvement? | |
| 08:39:00 | songwenping | gibi: i means this feature is not only for API, but include compute modify. | |
| 08:39:33 | gibi | it includes everythin (cinder and nova impacts) that allows reimaging the root volume of a VM booted from that volume | |
| 08:40:08 | gibi | so yes, it is not just an API change | |
| 08:42:19 | songwenping | thanks, got it. and what's the feature for 'the change to only accept importing a public key but also with an extended name pattern'. | |
| 08:44:52 | gibi | that is actually two features. 1) nova stoped supporting generating ssh keys, we only support importing ssh keys. (it is in a new microversion so old microversions still allow generating ssh keys) 2) we extended the list of allowed chars set for the name of the key. Now both @ and . is allowed in the name | |
| 08:52:55 | songwenping | thanks gibi, got it. | |
| 16:01:51 | open10k8s | Hi team, Task_state=deleting VMs don't exist on hypervisors but openstack keeps those list as Active and running. Nova-compute restart solves this but it is only a temporary solution. After delete another machine, same thing happens. I cannot find any error logs from nova services. Is this known issue in a specific condition or any workaround for this? | |
| 16:03:49 | open10k8s | I am running wallaby and never experienced this issue on other clouds with same version | |
| 16:09:02 | melwitt | open10k8s: no, that's not a known issue and it shouldn't be doing that. you are seeing this happen with all delete requests? if the actual VM is gone but the instance still listed, that means that somehow the delete did not reach the DB update to remove the instance record | |
| 16:09:35 | open10k8s | yes, all deletion operation | |
| 16:10:36 | melwitt | I would expect to see some evidence of why in the nova-compute and or nova-conductor logs. are you running logs with debug=True to diagnose? if there's no message in the logs, it will be difficult to find why it's happening | |
| 16:10:48 | open10k8s | i rather tried to find any issues on oslo messaging | |
| 16:11:39 | melwitt | yeah that is a good thing to look for, also the database if there's any issue there when nova-compute attempts to delete the instance record by way of the nova-conductor | |
| 16:12:00 | melwitt | but in both of those cases usually there is an error logged | |
| 19:33:15 | opendevreview | Ghanshyam proposed openstack/os-vif stable/stein: Fix zuul config error for os-vif https://review.opendev.org/c/openstack/os-vif/+/859892 | |
| 19:38:52 | opendevreview | Ghanshyam proposed openstack/os-vif stable/rocky: Fix zuul config error for os-vif https://review.opendev.org/c/openstack/os-vif/+/859893 | |
| #openstack-nova - 2022-09-30 | |||
| 06:48:35 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check if resized to swap zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 07:01:44 | amorin | hey nova team, if you have time someday to review this: https://review.opendev.org/c/openstack/nova/+/853682 | |
| 07:15:18 | Uggla | Poke bauzas --> https://photos.app.goo.gl/MRmeetQr749GFh3s5 ;) | |
| 07:31:11 | bauzas | danm fucking numpy | |
| 07:31:22 | bauzas | I should have prepared better | |
| 07:32:02 | bauzas | and now I have to wait until Feb 2023 IIRC | |
| 07:32:05 | bauzas | graaaah | |
| 07:34:23 | bauzas | oh no, actually after Mar 29th :( | |
| 09:15:42 | Uggla | gibi, bauzas could you have a look at https://review.opendev.org/c/openstack/nova/+/854355 | |
| 09:17:21 | bauzas | ouch. | |
| 09:17:50 | bauzas | Uggla: what do you mean by "soft delete is deprecated ?" | |
| 09:18:40 | Uggla | bauzas, This is mentioned and checked in a test that we should not create soft delete objects. | |
| 09:19:27 | bauzas | I'd say this isn't recommended, true | |
| 09:19:35 | bauzas | but "deprecated" seems harsh to me | |
| 09:20:01 | bauzas | like, if you signal that instances won't be soft deleted, it would be an operators revolution | |
| 09:21:36 | Uggla | bauzas, https://opendev.org/openstack/nova/src/commit/adeea3d5e7d7337d2817dd5c46334c76c05995ef/nova/tests/unit/db/test_models.py#L21 | |
| 09:22:14 | Uggla | I have just reuse the wording L54. | |
| 09:23:13 | Uggla | but I can change the wording if you wish. | |
| 09:29:24 | gibi | Uggla: done | |
| 09:30:00 | gibi | bauzas: what we want to say that no new ovo can be created with soft delete support | |
| 09:30:16 | gibi | and this is enforced by a test case as Uggla noted above | |
| 09:31:26 | bauzas | ok, the wording seems weird to me but when I read the original commit msg, this is saying the same | |
| 09:31:31 | bauzas | anyway | |
| 09:31:36 | bauzas | I knew about new tables | |
| 09:33:23 | Uggla | gibi, thx | |
| 09:37:20 | ralonsoh | gibi, hey, do you know how to book the operator-hour? | |
| 09:37:22 | ralonsoh | I tried "#operator-hour-neutron book icehouse-FriB1" | |
| 09:37:35 | ralonsoh | but I don't want to break anything testing other commands | |
| 09:38:00 | gibi | ralonsoh: I did not tried to book it. bauzas did you booked? | |
| 09:38:08 | ralonsoh | I did for neutron | |
| 09:38:15 | ralonsoh | but not for the operator-hour | |
| 09:38:36 | bauzas | ralonsoh: gibi: yeah I did it for the nova one | |
| 09:38:52 | bauzas | ralonsoh: but you need to ask the infra folks to add you as the neutron owner | |
| 09:38:57 | bauzas | sec | |
| 09:39:03 | ralonsoh | bauzas, I am | |
| 09:39:13 | ralonsoh | I already booked the neutron slots | |
| 09:39:20 | bauzas | https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html | |
| 09:39:35 | bauzas | you need to register the new track | |
| 09:39:38 | ralonsoh | ahhhhh | |
| 09:39:41 | ralonsoh | bauzas, thanks a lot | |
| 09:39:50 | bauzas | np | |
| 09:40:30 | bauzas | ralonsoh: that reminds me, I guess we will want a x-p session at the PTG between nova and neutron | |
| 09:40:46 | bauzas | so, let's just ask our folks if they want | |
| 09:40:56 | bauzas | and we'll try to find a slot | |
| 09:40:56 | ralonsoh | I think so, manly for live migration | |
| 09:41:04 | ralonsoh | do you have topics for it? | |
| 09:42:00 | bauzas | ralonsoh: none for the moment AFAICS | |
| 09:42:09 | ralonsoh | bauzas, I'll send a mail today | |
| 09:42:19 | ralonsoh | with a section in our etherpad | |
| 09:42:46 | bauzas | OK | |
| 10:23:45 | auniyal | Hello #openstack-qa | |
| 10:23:53 | auniyal | Hello #openstack-nova | |
| 10:24:07 | auniyal | I added a new flavor in here - https://opendev.org/openstack/nova/src/commit/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/tests/fixtures/nova.py#L731 | |
| 10:24:35 | auniyal | so updated this as well - https://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/api_sample_tests/api_samples/flavors/v2.75/flavors-list-resp.json.tpl | |
| 10:24:53 | auniyal | is there any other place I should update ? | |
| 10:25:43 | auniyal | right now, some functional tests are failing at here - https://opendev.org/openstack/nova/src/commit/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/tests/functional/api_samples_test_base.py#L399 | |
| 10:28:39 | auniyal | my added functional tests are passing, but existing tests are failing | |
| 10:29:09 | auniyal | these - https://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/api_sample_tests/test_flavors.py | |
| 10:31:37 | auniyal | gibi, bauzas ^^ | |
| 10:38:13 | stephenfin | bauzas: Does https://review.opendev.org/c/openstack/python-novaclient/+/816158 still need to be done (and backported)? | |
| 11:05:38 | opendevreview | Eigil Obrestad proposed openstack/nova-specs master: Compute Inventory Customization https://review.opendev.org/c/openstack/nova-specs/+/858858 | |
| 11:18:51 | opendevreview | Eigil Obrestad proposed openstack/nova-specs master: Compute Inventory Customization https://review.opendev.org/c/openstack/nova-specs/+/858858 | |
| 11:18:58 | obre | gibi, sean-k-mooney: Some clarifications and changes added ^^. Please have a look when time permits. As for workflow I wonder abot the comments: Should I mark comments as resolved when I answer them to signal that they are answered; or should you mark them as resolved to signal that my answer is accepted? | |
| 11:56:19 | frickler | has it ever been discussed to build some mechanism to allow instances to store their SSH host key in nova, so that users could get a certified instance/hostkey association from the API? rough idea would be to allow a POST to a special metadata API endpoint, which could be authenticated like other metadata accesses | |
| 11:58:22 | frickler | once that is done, one could extend neutron-designate integration to generate SSHFP records in addition to A+PTR | |
| 12:06:29 | gibi | obre: mark them resolved if you think you resolved them. We can always repoen it if think further discusion is needed | |
| 12:17:07 | opendevreview | Eigil Obrestad proposed openstack/nova-specs master: Compute Inventory Customization https://review.opendev.org/c/openstack/nova-specs/+/858858 | |
| 13:15:01 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check if resized to swap zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 13:34:06 | bauzas | stephenfin: good call about the client patches, I need to take a look at them | |
| 13:35:02 | bauzas | frickler: sounds to me something not nova-related | |
| 13:35:48 | bauzas | ie. you want some datastore to persist a tuple (instance, hostkey) | |
| 13:39:24 | frickler | bauzas: I think the verification of the instance ID would need to come from nova, else it could be spoofed from a different host | |
| 13:40:38 | frickler | some hacky workaround would be to have the instance output the key to the console log and just parse it from there, but that sounds a bit flaky | |
| 13:56:48 | bauzas | frickler: maybe I misunderstood your usecase | |
| 13:57:25 | bauzas | when ssh'ing the instance, you mean ? | |
| 13:57:51 | bauzas | we already have the fingerprint | |