Earlier  
Posted Nick Remark
#openstack-nova - 2022-05-18
14:58:24 gmann bauzas: this is code change ref author did for that spec - https://review.opendev.org/c/openstack/nova/+/781076/
14:58:48 gmann bauzas: yeah, I am +2 on spec, just waiting for melwitt if she has anything before +w.
15:12:15 gibi I left a question with a -1 on that ^^
15:23:17 bauzas gibi: replied https://review.opendev.org/c/openstack/nova-specs/+/840217/5/specs/zed/approved/keypair-generation-removal.rst#66
15:24:24 bauzas tl;dr: 'ssh' keytype is the default if the param is not passed
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: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040
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: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 sean-k-mooney with a lot of work
21:48:42 mnaser oh that's interesting lol
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

Earlier   Later