| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-29 | |||
| 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 | ralonsoh | I think so, manly for live migration | |
| 09:40:56 | bauzas | and we'll try to find a slot | |
| 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 | |
| 14:18:23 | frickler | bauzas: where do we have that? the use case is securing the initial SSH connection to a fresh instance, yes | |
| 14:59:41 | bauzas | frickler: https://docs.openstack.org/api-ref/compute/?expanded=show-keypair-details-detail#show-keypair-details | |
| 14:59:58 | bauzas | when you import a pubkey, then it creates the fingerprint | |
| 15:02:42 | frickler | bauzas: ah, but the issue is about the hostkey, not the user key. cloud-init can output it on the console but I would want a nicer solution https://stackoverflow.com/questions/66658406/openstack-how-to-find-out-vms-key-fingerprint-before-first-ssh-session | |
| 15:05:54 | frickler | the other option would be to have something similar like AWS IAM host roles and via that give cloud-init credentials with which it could talk to designate | |
| 15:09:26 | frickler | but maybe you are right and this is more an issue for neutron than for nova | |
| 15:11:31 | clarkb | frickler: yes mordred brought this up probably 8 years ago at this point. I think the idea then was maybe to have the hypervisor scan the hostkey since it can talk directly to the correct interface then report that back through the api | |
| 15:14:30 | frickler | clarkb: ah, scanning from the outside instead of relying on some action from the instance would make this more generally useful, that's a good point, too | |
| 15:26:02 | bauzas | frickler: hah, about the hostkety | |
| 15:26:12 | bauzas | I mean the compute node | |
| 15:26:30 | bauzas | then, as I said, not a nova usecase IMO | |
| 15:31:15 | clarkb | bauzas: why isn't that a nova use case? | |
| 15:31:28 | clarkb | nova is the only entity in a position to accurately query the info | |
| 15:31:54 | bauzas | clarkb: that's port-dependent on the host, right? | |
| 15:32:31 | clarkb | yes, you'd need to make a network request over the correct interface/port to accurately retrive the information | |