| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-29 | |||
| 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 | |
| 15:32:55 | clarkb | and you can't traverse additional network segments or you lose the accuracy | |
| 15:33:13 | bauzas | correct | |
| 15:33:24 | bauzas | so you can't rely on nova itself | |
| 15:33:52 | bauzas | but I'm open to discuss the usecase in a spec | |