Earlier  
Posted Nick Remark
#openstack-nova - 2022-05-17
13:11:36 bauzas sean-k-mooney: you can import a x508 public key https://github.com/openstack/nova/blob/972c06c608f0b00e9066d7f581fd81197065cf49/nova/api/openstack/compute/keypairs.py#L105
13:11:43 sean-k-mooney yes i know
13:11:56 sean-k-mooney that was never in doubt at least in my mind
13:12:16 bauzas if so, we create a fingerprint
13:12:25 sean-k-mooney i was not sure if we could generate them but we can
13:12:37 bauzas sean-k-mooney: you can generate them too
13:12:43 sean-k-mooney yes i know i found the code
13:12:50 sean-k-mooney so i dont want the capablities to differ per type
13:12:56 bauzas yes
13:13:08 sean-k-mooney so i dont want to kep generateion for x509 but drop it for ssh in teh new microverion
13:13:08 bauzas so I'll remove this in the spec
13:13:13 sean-k-mooney ack
13:13:22 sean-k-mooney so we will remvoe generation for all types
13:13:31 sean-k-mooney but keep type in the api for import and list
13:13:37 sean-k-mooney correct?
13:13:50 sean-k-mooney and keep the generation code for older microverions
13:14:58 bauzas sean-k-mooney: yes, just stoping to accept no public key
13:15:11 bauzas by the new microversion, yes
13:15:28 sean-k-mooney that works for me
13:29:50 opendevreview Sylvain Bauza proposed openstack/nova-specs master: Proposes to remove keypair generation https://review.opendev.org/c/openstack/nova-specs/+/840217
13:54:23 kashyap gibi: FFS, now CentOS9S seem to fail this - https://review.opendev.org/c/openstack/nova/+/838926
13:54:41 kashyap I just can't seem to get rid off my back
13:55:17 kashyap It's another unrelated random timeout: https://zuul.opendev.org/t/openstack/build/bcaf2154eeb545cdb7907d0c807513e9
14:23:19 gibi kashyap: that was another disk detach issue
14:31:00 sean-k-mooney should we make the c9s job non-voting
14:31:12 sean-k-mooney i have seen that fail quite offen with the detach issue
14:34:33 kashyap gibi: Oh, damn; is that a real one?
14:35:03 kashyap sean-k-mooney: Yeah, we should until that known issue is resolved. I wonder if others disagree
14:35:04 sean-k-mooney kashyap: i dont think its realated to your patch if that is what you are asking
14:35:17 gibi I think we are still in the progress of landing the tempest patches that adds the waiter unit the guest boots up
14:35:26 sean-k-mooney kashyap: but device detach is really really falky on centos 9
14:35:31 kashyap sean-k-mooney: No; I was asking if it's an unrelated new issue :)
14:35:40 gibi it is not new
14:35:47 gibi and it is not related to your patch
14:35:47 sean-k-mooney kashyap: its unrelated to your patch
14:36:01 kashyap (Yep, noted)
14:38:00 sean-k-mooney gibi: i tought the tempest chagnes were landed on master
14:39:36 sean-k-mooney https://review.opendev.org/q/topic:wait_until_sshable_pingable
14:39:57 sean-k-mooney so https://review.opendev.org/c/openstack/tempest/+/817772?
14:41:07 sean-k-mooney hum tempest.api.compute.volumes.test_attach_volume.AttachVolumeMultiAttachTest
14:41:09 sean-k-mooney is what failed
14:41:14 sean-k-mooney so maybe that is not useing that yet
14:42:02 sean-k-mooney apprently it is https://github.com/openstack/tempest/blob/master/tempest/api/compute/volumes/test_attach_volume.py
14:42:55 sean-k-mooney perhaps test_resize_server_with_multiattached_volume is not
14:43:00 gibi I noted this particular failure in https://bugs.launchpad.net/nova/+bug/1960346/comments/29
14:43:25 sean-k-mooney ah
14:43:27 sean-k-mooney https://github.com/openstack/tempest/blob/master/tempest/api/compute/volumes/test_attach_volume.py#L495=
14:43:46 sean-k-mooney so we need to wait after that resize
14:43:55 gibi after resize we only wait for ACTIVE state then go and detach
14:43:58 sean-k-mooney or in teh resize call we need to wait for it to be sshable again
14:44:02 gibi yepp
14:44:03 sean-k-mooney ya
14:44:37 sean-k-mooney ok i dont see a patch for that in the seriese at least not on the topic
14:44:50 sean-k-mooney but that makes sense why this is still failing
14:44:51 gibi probably it is easier to grep for detach calls and put a wait before them
14:45:28 gibi gmann: fyi ^^ https://bugs.launchpad.net/nova/+bug/1960346/comments/29
14:45:39 sean-k-mooney perhaps
14:45:47 sean-k-mooney so we could put a wait here https://github.com/openstack/tempest/blob/569c7a89f54c94494fde46ce2aa4fbd26492e640/tempest/api/compute/base.py#L459-L469=
14:46:07 sean-k-mooney or
14:46:12 sean-k-mooney we could put a wait here https://github.com/openstack/tempest/blob/569c7a89f54c94494fde46ce2aa4fbd26492e640/tempest/api/compute/base.py#L547=
14:46:14 sean-k-mooney in detach
14:47:25 sean-k-mooney if we do it in detach it shoudl alway ensure that we check its sshabel when we are about to detach but we woudl likely need a flag to hadnel teh vm state
14:47:30 sean-k-mooney e.g. if its not active
14:48:29 gibi yeah
14:49:25 sean-k-mooney personally while i dont really liek the wackamole approch i would prefer not to put it in detach
14:49:49 sean-k-mooney so put it in reszie ectra as those operations already have the instance and are changing the state
14:52:37 gibi but not all VM lifecycle operation, not all resize, will be followed by a detach
14:53:03 gibi so it is a waste to wait if no detach is done later
14:53:05 sean-k-mooney yes but we could wait in all cases whre we expect the vm to be active
14:53:59 sean-k-mooney ya so it a questoin of how much knolage we want the autor and review of tempest chagne to need
14:54:18 sean-k-mooney we can be extra safe and alway wait when ever we expect a vm to be active
14:54:29 sean-k-mooney or we can put it in only when we expect to do a detach
14:54:52 sean-k-mooney in which case we shoudl not modify resize or detach and just add the wait in the respective tests
14:56:49 sean-k-mooney i think the pattern they are taking is to pass sshable to wait_until
14:56:56 sean-k-mooney and do that at the call site
14:57:31 sean-k-mooney as was done here https://review.opendev.org/c/openstack/tempest/+/840112/2/tempest/api/compute/base.py
14:57:53 sean-k-mooney so we woudl add wait_until='ACTIVE' a paramater to resize
14:58:11 sean-k-mooney and pass wait_until='SSHABLE' in that test that is failing when we call resize_server
14:58:25 gibi I think that wait_until thing is specificly for create_server
14:59:08 gibi we need to extend resize_server to make the wait
15:00:31 gibi there is even something called as a validation resource to be passed around
15:01:57 gibi ... I'm putting something together...
15:03:15 sean-k-mooney i tought it was passed to waiters.wait_for_server_status
15:04:05 sean-k-mooney hum perhaps not
15:04:24 sean-k-mooney gibi: it was not ment to be specific to create server
15:05:13 sean-k-mooney we have the genirc waiters https://review.opendev.org/c/openstack/tempest/+/817635/15/tempest/common/waiters.py#576
15:06:23 sean-k-mooney but ya its not plumed into the wait for status waiter at leas not in that patch
15:06:42 gibi yeah it is complicated as you need ssh set up including networking and keyts
15:06:45 gibi keys
15:07:15 sean-k-mooney yep the pingable version was ment to aovid that
15:07:27 sean-k-mooney you still need sec groups and network config
15:07:34 sean-k-mooney but slightly less overhead
15:08:01 sean-k-mooney in anycase it makes sense why resize is still flaky
15:09:04 gibi yepp
15:13:37 bauzas reminder : nova meeting in 47 mins here
15:15:04 gmann bauzas: sean-k-mooney: I am on same page for key generation things 1. remove only key generation support 2. keep 'type' as it is
15:15:16 bauzas ++
15:19:19 gmann gibi: sean-k-mooney I am not surprise on c9s job unstable.
15:19:21 gibi sean-k-mooney, kashyap, gmann: https://review.opendev.org/c/openstack/tempest/+/842140
15:19:44 sean-k-mooney gmann: do you know why that was made voting?

Earlier   Later