Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-17
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?
15:20:00 sean-k-mooney i was not expecting to have a voting job yet
15:20:12 gmann gibi: sean-k-mooney but we should not make SSH-able by deafult in base class for all test but 842140 approach is good
15:20:36 gmann sean-k-mooney: because it was passing and we want to see how long it will :)as non voting goes unmonitored
15:21:01 sean-k-mooney gmann: right but for nova we had said we did want it to be voting intially at the ptg
15:21:08 gmann gibi: sean-k-mooney I think we can do those grep for detach and make them SSH-able. I tried to do in that series but might not have finished
15:21:14 sean-k-mooney so i was surpsed ot see it in the nova gate
15:21:33 sean-k-mooney sicne we had not got around to creating the nova-next centos job yet
15:21:50 sean-k-mooney but i guess the templats got updated?
15:21:58 gmann sean-k-mooney: you mean 'did not want it to be voting' if 'did want it to be voting' ?
15:22:28 gibi actually I'm fine that is voting, this way we are forced to fix these missing waiters
15:22:36 sean-k-mooney we intially did not want he centos job to be voting in nova. i was suggesting adding one based on nova-next
15:22:49 kashyap gibi: Oh, cool
15:22:50 kashyap wait_until in ("SSHABLE", "PINGABLE") and
15:22:51 kashyap CONF.validation.run_validation
15:23:00 sean-k-mooney gibi: well im ok with it but i was expecting use to let it bake for a while
15:23:28 gmann if detach things is only failing we ill keep identified the test waiting for SSH-able or can grep in advance.
15:23:39 gmann and if more other failure start then we can think of making it non voting/
15:24:14 gibi gmann: ack
15:25:44 sean-k-mooney gmann: gibi actully i guess the issue is i missed this https://github.com/openstack/nova/commit/ed3abea3b239044bf72277d548da5e2277aed8f5
15:26:19 sean-k-mooney gibi: i did not think we had added centos based testing in or check/gate pipeline yet at all
15:26:45 sean-k-mooney so when i brought it up in the ptg i was epecting to let it bake for a few months
15:26:52 gmann sean-k-mooney: yeah, centos stream is first we are trying i think and c9s as voting
15:26:56 sean-k-mooney before making it voting
15:27:27 sean-k-mooney gmann: is this happing in other project too
15:27:51 gmann but I am not saying we have to it is like if they are stable we keep them voting and if unstable and no help from centos community then we can think of removing the distro testing frmo testing runtime. example opensuse
15:27:55 sean-k-mooney because we wanted to add it to nova to test very speicific things namely newer libvirt and q35 by defualt
15:28:26 gmann sean-k-mooney: happening failure or making it voitng?
15:28:30 sean-k-mooney gmann: the testing runtime dose not define what os we test on in the indivigual projects
15:29:00 gmann sean-k-mooney: we define minimum expectation of testing and those are needed to be stable as base distro or QA support
15:29:04 sean-k-mooney as in centos being listed in the testing runtime has never ment that nova or neutron tested with it
15:29:56 sean-k-mooney gmann: centos has been in the pti for years but it was only added to nova in yoga by gibis patch
15:30:02 gmann sean-k-mooney: it is not like that, it is meant as a minimum expectation from every project but as devstack itself and our CI/CD is mostly on ubuntu we are doing that only and centos etc are mostly tested in tripleo or so
15:30:26 sean-k-mooney gmann: right i am privding feed back that that is not how it has worked previously
15:30:30 gmann sean-k-mooney: not by gibi patch, it is made voting in tempest side I think lee adedd this c8s integrated job
15:30:43 sean-k-mooney so form my persepitve this is a change in expecation from teh QA team
15:31:06 gmann sean-k-mooney: I know, we are trying if c9s as base can be stable as that is must needed for FIPS testing also which a community wide goal now.
15:31:38 sean-k-mooney yep im aware of the fips intersect
15:31:56 gmann sean-k-mooney: if c9s is not stable we will make it clear 1. can centos community help in making it stable 2. if no then let's not spend time on this and drop the entire support like opensuse we did
15:32:10 bauzas I said it downstream but I saw something fun : https://blueprints.launchpad.net/nova/+spec/update-userdata Registered by Steve Baker on 2013-10-07
15:32:16 gmann and having them voting is my main goal to know the data
15:32:37 bauzas on that date, I was just starting to work on Nova :)
15:32:43 sean-k-mooney gmann: right so when i brogt it up at the ptg for the last 3 ptgs or more
15:32:47 bauzas and my kid was 3yo :)
15:33:01 sean-k-mooney i started with not having it voting ot not blocke patche merging until it was table
15:33:16 sean-k-mooney gmann: i wanted to have it voting eventuly too
15:33:36 sean-k-mooney and mensiton using fips testing as one of the reasons to do this as well as teting newer libvirt
15:33:44 sean-k-mooney gmann: so i think we are aligned
15:34:00 sean-k-mooney just was not expecting it to be voting until m2 honestly
15:34:19 gmann sean-k-mooney: yeah, I think we are saying same thing. if that become unstable we will make it non voting even that is what QA plan is. but as long as it is passing (we will fix the detach things) it is ok to try
15:34:49 sean-k-mooney gmann: untill we fix the detach thing i think its unstable which is why
15:35:03 sean-k-mooney lee had a patch to change it to voting at the end of the sshable series

Earlier   Later