| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-18 | |||
| 14:03:17 | sean-k-mooney | gibi: hum https://review.opendev.org/c/openstack/tempest/+/842140 still failed the same way | |
| 14:03:23 | sean-k-mooney | frickler: ^ any idea why | |
| 14:05:13 | gibi | sean-k-mooney: yeah, this is where my tempest knowledge ends. probably something is different in the network setup of this test | |
| 14:05:20 | frickler | sean-k-mooney: I'll take a look later, in a meeting now | |
| 14:05:51 | sean-k-mooney | gibi: possible i can see in the tempest output it waited for it to go form resize verify to active | |
| 14:05:56 | sean-k-mooney | and tehn it tries to ssh in | |
| 14:06:02 | sean-k-mooney | but it didn not work | |
| 14:07:20 | sean-k-mooney | "fixed_ip_address": "10.1.0.10" | |
| 14:07:22 | sean-k-mooney | ip-route:10.1.0.0/28 dev eth0 scope link src 10.1.0.10 | |
| 14:07:54 | sean-k-mooney | ah | |
| 14:08:11 | sean-k-mooney | ## ping -c 5 10.1.0.1 | |
| 14:08:13 | sean-k-mooney | PING 10.1.0.1 (10.1.0.1): 56 data bytes | |
| 14:08:15 | sean-k-mooney | --- 10.1.0.1 ping statistics --- | |
| 14:08:17 | sean-k-mooney | 5 packets transmitted, 0 packets received, 100% packet loss | |
| 14:08:20 | sean-k-mooney | the vm cannot ping its gateway | |
| 14:10:14 | sean-k-mooney | gibi: my guess is security groups | |
| 14:12:06 | bauzas | gmann: to clarify the new release naming thingy, it would be something like "2022.2 Arbitrary" for the AA release ? | |
| 14:12:28 | bauzas | where "Arbitrary" be chosen by the Foundation folks | |
| 14:12:29 | bauzas | right? | |
| 14:13:02 | sean-k-mooney | where "Arbitrary" is aardvark so say it dansmith :) | |
| 14:13:24 | sean-k-mooney | havnt actully read the most recent status of this | |
| 14:13:33 | sean-k-mooney | so also interested | |
| 14:13:39 | dansmith | I would love them to choose such a name to make my point, but yes, it's going to be aardvark :) | |
| 14:13:57 | dansmith | the name will be the name, the version will be 2022.2 | |
| 14:17:43 | sean-k-mooney | gibi: it might be becasue the server is not being created with teh validation resouces initally | |
| 14:17:53 | bauzas | dansmith: if it was named a-ha, it could take on me | |
| 14:17:58 | sean-k-mooney | gibi: so it might not hwave an sshkey | |
| 14:18:13 | gibi | sean-k-mooney: OK, that I can fix | |
| 14:18:21 | dansmith | bauzas: you win today | |
| 14:18:23 | sean-k-mooney | gibi: we are not calling https://review.opendev.org/c/openstack/tempest/+/842140/4/tempest/api/compute/volumes/test_attach_volume.py#45= | |
| 14:18:25 | gibi | thanks for looking at it | |
| 14:18:53 | sean-k-mooney | here https://review.opendev.org/c/openstack/tempest/+/842140/4/tempest/api/compute/volumes/test_attach_volume.py#384 | |
| 14:19:07 | bauzas | dansmith: heh, thanks for the explanation anyway | |
| 14:19:26 | sean-k-mooney | so we are not waiting for the server to be sshable before we attach the multi attach volume | |
| 14:20:14 | sean-k-mooney | a is for aardvark is an amican thing we normally say ant or similar | |
| 14:20:38 | dansmith | it's perfect because it starts with AA | |
| 14:20:44 | sean-k-mooney | yep | |
| 14:20:52 | dansmith | I challenge the rest of you to pick names for the other letters that begin thusly :) | |
| 14:25:20 | sean-k-mooney | dansmith: the real question is the next AB or BB becaue one is much more of a challange | |
| 14:25:50 | dansmith | sean-k-mooney: well, I had assumed BB, but maybe AB would be appropriate for the naming | |
| 14:25:59 | dansmith | however, I think all the things would have to start with A and somewhat defeat the point | |
| 14:26:08 | dansmith | however, these are the foundations' problems now :) | |
| 14:27:03 | sean-k-mooney | this is not what i was looking for but its cute so https://www.pinterest.ie/morganlimehouse/bb-animals/ | |
| 14:28:09 | bauzas | AB are two capital letters known a lot by French | |
| 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 | |