| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-30 | |||
| 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? | |
| 22:08:58 | sean-k-mooney | you should be able to just do a server delete | |
| 22:09:16 | sean-k-mooney | if you cant then you have a broken deployment and you need to triage why the request is failing | |
| 22:09:45 | sean-k-mooney | did you try deleteing with the uuid | |
| 22:09:52 | sean-k-mooney | rahter then the name | |
| 22:10:12 | sean-k-mooney | if that fails you should check the nova-api to see if there is an internal excption | |
| 22:10:37 | atmark | i'm deleting by uuid but response is no name or ID or exists | |
| 22:11:07 | atmark | i think this an old instance from last year | |
| 22:11:19 | sean-k-mooney | ack there is obviouly an error internally without knowing what that is there is not much more i can suggest | |
| 22:11:32 | sean-k-mooney | if you take the request id you shoudl be able to find it in the api logs | |
| 22:11:47 | atmark | i'm doing cleanup atm and just caught one on weird state | |
| 22:12:07 | sean-k-mooney | its possible that it exists in teh api db but not in the cell db | |
| 22:12:22 | sean-k-mooney | if you do a server show does it have a host | |
| 22:12:29 | atmark | no | |
| 22:12:57 | sean-k-mooney | ok so its before the schuiler has selected one most likely | |
| 22:13:43 | atmark | https://paste.openstack.org/show/bXZv2CMnmfdGeswoUKUC/ | |
| 22:14:23 | atmark | VM is octavia amphorae | |
| 22:14:48 | sean-k-mooney | --all is all tenants | |
| 22:15:04 | sean-k-mooney | is that owned by your current project | |
| 22:15:18 | johnsom | Yep, the instance is owned by the Octavia service account. | |
| 22:15:49 | atmark | yes, i have admin access to all tenants | |
| 22:15:49 | sean-k-mooney | no what i mean is when openstack server delete 6fb27c67-539c-4525-8747-e26487d15e75 is run | |
| 22:15:52 | sean-k-mooney | what user is that | |
| 22:16:04 | sean-k-mooney | ok so thats an admin user | |
| 22:16:41 | sean-k-mooney | i think you should be able to delete the vm then even if your current token is not for the correct project due to admin right if you are not using new policy | |
| 22:17:30 | sean-k-mooney | the server show is implying that its not in the current project | |
| 22:17:46 | sean-k-mooney | so i was wondering if the delete was failing for the same reason | |
| 22:18:04 | johnsom | There is a --all-projects for the server delete command too, just like for list. | |
| 22:18:13 | sean-k-mooney | i tought admins could bypass that check | |
| 22:18:25 | johnsom | I thought so too honestly | |
| 22:19:04 | sean-k-mooney | its been a while since i have done that so cant recall if you need to set the project id somehow or not | |
| 22:20:17 | atmark | openstack server --os-project-id 848fe125a93a408ba8a8044fb87e9cdf delete 6fb27c67-539c-4525-8747-e26487d15e75 | |
| 22:20:48 | atmark | 848.. is tenant ID of octavia | |
| 22:22:19 | sean-k-mooney | that would require your current user to have the member or admin role on that project for keystone to be able to issue the token | |
| 22:22:40 | sean-k-mooney | the uuid shoudl be enough if your an admin | |
| 22:22:51 | sean-k-mooney | --all-project is only required to delete by name | |