| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-18 | |||
| 15:24:59 | bauzas | which makes sense, as the fingerprint only needs to be generated differently if this comes from a x509 cert | |
| 15:25:46 | gibi | replied | |
| 15:26:00 | gibi | does it make sense to return type ssh for x509 keypairs ? | |
| 15:27:01 | sean-k-mooney | not realy | |
| 15:27:09 | sean-k-mooney | x509 is for winrm | |
| 15:27:11 | sean-k-mooney | not ssh | |
| 15:27:17 | sean-k-mooney | it can be used for other things | |
| 15:27:47 | sean-k-mooney | we just assume the user will tell us if its not ssh | |
| 15:27:53 | gibi | I think today if no type is specified and an x509 key is imported nova will save type=ssh for it | |
| 15:27:55 | sean-k-mooney | but we dont really use that for anything | |
| 15:28:01 | bauzas | gibi: no it won't work | |
| 15:28:33 | gibi | we dont use type but we do return it on the API | |
| 15:28:36 | bauzas | gibi: because the fingerprint will be generated using a SSH way | |
| 15:28:46 | sean-k-mooney | bauzas: what fingreprint | |
| 15:28:54 | sean-k-mooney | we are uploading the fingerprint right | |
| 15:29:07 | bauzas | gibi: atm, if you import a pubkey, nova generates a fingerprint using the key type you provided, or ssh as default | |
| 15:29:19 | bauzas | sean-k-mooney: no, we're generating it | |
| 15:29:23 | bauzas | https://github.com/openstack/nova/blob/4939318649650b60dd07d161b80909e70d0e093e/nova/compute/api.py#L6658 | |
| 15:29:24 | sean-k-mooney | when you use x509 you would import the fingerprint the same way we impor the public key | |
| 15:29:29 | gmann | I think gibi point is valid, one way is to mention in api-ref that we should expect 'type' if importing x509 otherwise it will be default to ssh | |
| 15:29:54 | gmann | or return None as default if not passed | |
| 15:30:12 | gibi | can we make ``type`` required in this new api microversion | |
| 15:30:13 | gibi | ? | |
| 15:30:15 | bauzas | sean-k-mooney: https://github.com/openstack/nova/blob/4939318649650b60dd07d161b80909e70d0e093e/nova/compute/api.py#L6729-L6733 | |
| 15:30:21 | sean-k-mooney | hum ok | |
| 15:30:31 | bauzas | gibi: looks to me a bikeshed | |
| 15:30:53 | bauzas | gibi: 99% of users will import an openssh generated key | |
| 15:31:23 | gmann | yeah, I think returning None as default s ok as that is what pattern we use in API where we return the things which are passed | |
| 15:31:31 | gibi | OK, then check the imported key and if it is not ssh then set the type accordingly automatically | |
| 15:31:35 | bauzas | but the 1% of opiniated users that wanna use x509 certs will make sure they correctly set the type, like we did previously | |
| 15:31:54 | bauzas | gmann: gibi: I don't see the need for a breaking change here | |
| 15:32:10 | bauzas | we just want to stop generating a key | |
| 15:32:26 | bauzas | for pubkey imports, I don't think we should change anything | |
| 15:33:18 | gmann | but if we see from user point of view that generating fingureprint as ssh for x509 if type is not passed is also wrong https://github.com/openstack/nova/blob/4939318649650b60dd07d161b80909e70d0e093e/nova/compute/api.py#L6729-L6733 | |
| 15:33:46 | gmann | bauzas: yeah, it will be same as it is currently so this is not new things we are adding in this spec | |
| 15:34:27 | gmann | I mean no 'type' in request create same mismatch currently also and after this spec also. | |
| 15:34:45 | bauzas | gmann: gibi: honestly, I'm more intended to document this in the API reference but not make it mandatory | |
| 15:34:55 | bauzas | it will be a PITA for 99% of our users | |
| 15:35:18 | bauzas | like, "type is optional but defaulted to ssh, you're warned" | |
| 15:35:24 | gmann | that work for me, having it in api-ref is enough i think. | |
| 15:36:03 | bauzas | I'll just change the apiref parameter documentation for all the microversions, since this is already the same | |
| 15:36:07 | gmann | I am ok with either 1. in api-ref 2. return as None but not in favor of making it mandatory | |
| 15:36:34 | bauzas | gmann: none is meaningless since we especially generated a fingerprint using the openssh toolbox | |
| 15:36:50 | gmann | yeah that too | |
| 15:37:16 | bauzas | actually, not by openssh itself, but folliwing the openssh reference (base64) | |
| 15:37:25 | gmann | bauzas: +1 on api -ref and yes that can be done for all microversion not specific to this one | |
| 15:38:25 | bauzas | gmann: want me to write it down on the spec ? | |
| 15:39:27 | gmann | bauzas: I do not think that is needed as it is same behavior currently also and we are just documenting it. | |
| 15:40:03 | bauzas | gmann: cool, then I'll add a comment in the spec change | |
| 15:40:16 | bauzas | at least if gibi is happy with this | |
| 15:40:37 | gmann | yeah | |
| 16:04:54 | gibi | bauzas: yes this "bug" exists today regardless of your spec, but as your spec bumping the microversion for keypairs I thought we could fix this in the same microversion | |
| 16:06:50 | gibi | but I digress. Lets at least document this behavior in the API ref | |
| 16:06:57 | gibi | I'm removing my -1 | |
| 16:07:30 | gibi | done | |
| 16:09:42 | opendevreview | Stephen Finucane proposed openstack/osc-placement master: Remove six https://review.opendev.org/c/openstack/osc-placement/+/842386 | |
| 16:11:17 | opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 16:13:13 | bauzas | gibi: <3 | |
| 16:43:19 | melwitt | stephenfin: did you see this and the patch above it? https://review.opendev.org/c/openstack/osc-placement/+/812262 I had thought I had seen some remove six patches before and found these | |
| 16:59:51 | opendevreview | Erlon R. Cruz proposed openstack/nova stable/xena: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/838550 | |
| 16:59:52 | opendevreview | Erlon R. Cruz proposed openstack/nova stable/xena: Fix pre_live_migration rollback https://review.opendev.org/c/openstack/nova/+/836015 | |
| 18:33:53 | opendevreview | Merged openstack/osc-placement master: Remove usage of six https://review.opendev.org/c/openstack/osc-placement/+/812262 | |
| 18:38:01 | opendevreview | Merged openstack/osc-placement master: Remove usage of six https://review.opendev.org/c/openstack/osc-placement/+/815223 | |
| 19:11:26 | opendevreview | Merged openstack/nova stable/stein: [stable-only] Drop lower-constraints job https://review.opendev.org/c/openstack/nova/+/838038 | |
| 21:15:45 | opendevreview | sean mooney proposed openstack/nova master: [DNM] allow monkey patching spawn_n to spawn https://review.opendev.org/c/openstack/nova/+/842359 | |
| 21:15:45 | opendevreview | sean mooney proposed openstack/nova master: DNM: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040 | |
| 21:44:48 | mnaser | has anyone been able to successfully run pep8 .. locally? | |
| 21:45:02 | mnaser | got a bunch of failures on stable/wallaby .. `nova/virt/libvirt/driver.py:621:12: error: Cannot determine type of '_disk_cachemode'` | |
| 21:45:11 | sean-k-mooney | am yes | |
| 21:45:25 | sean-k-mooney | im just about to finish for the day again but i can try it quickly | |
| 21:45:32 | mnaser | i'm on macos so im wondering if there's something in the py version i'm running | |
| 21:45:51 | mnaser | i have py 3.8.9 | |
| 21:45:55 | sean-k-mooney | perhaps we dont relaly supprot anything other then linux | |
| 21:46:13 | sean-k-mooney | we used to be able to run them on cygwin but that was broken a long time ago | |
| 21:46:15 | mnaser | yeah but it seems weird/odd that mypy stuff would fail | |
| 21:46:21 | mnaser | since that seems more of a linter | |
| 21:46:28 | sean-k-mooney | my mac is downstiar i could try that there too | |
| 21:47:06 | mnaser | maybe i should use multipass or whatnot | |
| 21:48:00 | sean-k-mooney | or you could dual boot linux on your mac | |
| 21:48:11 | sean-k-mooney | it should work however | |
| 21:48:16 | mnaser | i think with an m1 mac that's a bit of a reach yet :P | |
| 21:48:24 | sean-k-mooney | nope | |
| 21:48:30 | sean-k-mooney | i have dual booted debian | |
| 21:48:36 | sean-k-mooney | and even got devstack to run | |
| 21:48:42 | mnaser | oh that's interesting lol | |
| 21:48:42 | sean-k-mooney | with a lot of work | |
| 21:49:04 | sean-k-mooney | but the unit test worked on both arch and debian | |
| 21:49:28 | mnaser | i feel like a lot of things won't work though, so multipass / vm is a decent middle ground :p | |
| 21:49:36 | sean-k-mooney | booting a vm on linux id cause a kernel crash however | |
| 21:49:54 | sean-k-mooney | ya i used udm too | |
| 21:50:02 | sean-k-mooney | that actully works pretty well | |
| 21:50:14 | sean-k-mooney | udm to deploy a ubuntu 20.04 arm vm | |
| 21:50:21 | sean-k-mooney | and then install what you want in that | |
| 21:50:59 | mnaser | udm? | |
| 21:51:12 | sean-k-mooney | udm is a front end for qemu on mac | |
| 21:51:36 | sean-k-mooney | hum is it udm | |
| 21:51:54 | mnaser | udm is "université de montréal" for what i know :p | |
| 21:52:06 | sean-k-mooney | oh utm | |
| 21:52:12 | sean-k-mooney | https://mac.getutm.app/ | |
| 21:52:44 | sean-k-mooney | i just used this template https://mac.getutm.app/gallery/ubuntu-20-04 | |