Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-18
14:28:28 bauzas lots of french cheapy soap series
14:32:13 opendevreview sean mooney proposed openstack/nova master: DNM: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040
14:32:13 opendevreview sean mooney proposed openstack/nova master: [DNM] allow monkey patching spawn_n to spawn https://review.opendev.org/c/openstack/nova/+/842359
14:37:37 opendevreview sean mooney proposed openstack/nova master: DNM: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040
14:37:37 opendevreview sean mooney proposed openstack/nova master: [DNM] allow monkey patching spawn_n to spawn https://review.opendev.org/c/openstack/nova/+/842359
14:53:08 gmann bauzas: dansmith sean-k-mooney on release name, we still discussing how to use it in development cycle (number only or number and name both ), should be ready by this week (plan to discuss in TC meeting tomorrow ) - https://review.opendev.org/c/openstack/governance/+/841800
14:53:19 gmann but yes, name will be all foundation things now
14:54:54 bauzas Uggla: sean-k-mooney: dansmith: gibi: gave -1 for https://review.opendev.org/c/openstack/nova-specs/+/831506 just to make sure we have a consensus
14:56:51 gmann bauzas: sean-k-mooney on keypair allowing @|. as it will be error -> success, it is ok for backward compatibility but we need to have microversion for interoperability
14:57:26 Uggla bauzas, no pb. I agree. Have you seen my proposal to add another API parameter to mange the pin/unpin az of instances ?
14:57:28 bauzas gmann: ok, so we would be only accepting those only by the new microversion, reight?
14:58:05 gmann bauzas: yes
14:58:15 bauzas gmann: ok, then that's what I wroter
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

Earlier   Later