| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-30 | |||
| 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 | |
| 15:33:56 | bauzas | or even at the PTG | |
| 15:34:15 | bauzas | I guess this is for blessing the instance ssh connection ? | |
| 15:34:23 | clarkb | ya ultimately I don't really care what implements it, but I do think being able to get the host key from nova show and be able to trust it is a very useful feature | |
| 15:34:41 | clarkb | bauzas: yes, it is so that you don't have to take a leap of faith the first time you make an ssh connection that you are not being mitm'd | |
| 15:35:09 | bauzas | clarkb: but then the connection to the port is managed thru neutron | |
| 15:35:47 | bauzas | but maybe that's something we can sort out at the PTG | |
| 15:35:48 | clarkb | but it is a host attribute. Your ports may come and go but the hostkey doesn't necessarily change | |
| 15:35:52 | bauzas | I understand the usecase | |
| 15:36:02 | clarkb | it may ultimately require cooperation between the compute and network layers | |
| 15:36:04 | bauzas | this is OS-specific tho | |
| 15:36:14 | clarkb | well it is ssh specific | |
| 15:36:16 | bauzas | actually no | |
| 15:36:18 | bauzas | yeah that | |
| 15:36:28 | clarkb | windows and solaris and linux and osx can all run an sshd | |
| 15:36:33 | bauzas | yeah | |
| 15:37:17 | bauzas | anyway, I'm not eventually against the usecase, I think we can agree it's a valid one | |
| 15:37:24 | bauzas | now the problem is how to get this | |
| 15:37:27 | bauzas | and how to present this | |
| 15:44:15 | clarkb | yup, I think the raeson it hasn't been done is that it is complicated | |
| 22:06:01 | atmark | how to properly to delete a VM stuck on BUILD status? openstack server delete throws no server with name or ID exists | |
| 22:07:07 | sean-k-mooney | that is the correct way if we have gotten to the point of creating a instance object in the db | |
| 22:07:30 | sean-k-mooney | if its stuck before that point then there should be no recored to delete | |
| 22:08:14 | atmark | server list still list the instance | |
| 22:08:35 | atmark | how can I get rid of the record? | |