Earlier  
Posted Nick Remark
#openstack-nova - 2021-01-19
17:55:09 gmann dansmith: multinode you mean this right ( not grenade-multinode ) nova-grenade-multinode ?
17:55:21 dansmith sure
17:56:00 gmann dansmith: it run live migration tests too https://github.com/openstack/nova/blob/master/playbooks/legacy/nova-grenade-multinode/run.yaml#L58
17:56:39 dansmith gmann: right, but is there anything fundamental about the base grenade job that we don't or can't do in the multinode variant such that we could stop running the base grenade job?
17:56:52 gmann dansmith: or you are thinking to drop grenade-py3 in favor of nova-grenade-multinode which cover upgrade + live migration?
17:56:59 gmann dansmith: right,
17:57:07 dansmith right
17:57:49 gmann I think yes, that make sense. in grenade-py3 we only run smoke test so it is a rick set of test we run there so nova-grenade-multinode server the purpose
17:57:53 gmann serve
17:57:54 sean-k-mooney dansmith: im not sure we rung the same test in both
17:58:27 dansmith gmann: cool, that'd be another ~1h job we run less
17:58:37 dansmith sean-k-mooney: I think the multinode job is a superset, no?
17:58:38 sean-k-mooney if its the same tests and same backend e.g. ceph vs non ceph i think we are ok
17:59:01 gmann dansmith: +1
17:59:13 sean-k-mooney dansmith: im not sure if we use the same storage backend in both
17:59:47 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: libvirt: Add support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/771474
18:00:06 dansmith gmann: okay, what's the magic to make zuul not run a job we inherited? :)
18:00:30 dansmith sean-k-mooney: I think those jobs are just stock storage config aren't they?
18:00:41 lyarwood gmann / dansmith ; just a quick point, at the moment the multinode job is still stuck on bionic
18:00:47 sean-k-mooney ya i would expect so
18:00:49 lyarwood but the single node job is on focal
18:01:01 sean-k-mooney so likel cinder isci/lvm
18:01:03 dansmith lyarwood: okay, but for grenade things is that significant?
18:01:05 lyarwood I'm not sure if we want to drop the single node job until the multinode job has moved finally
18:01:48 sean-k-mooney there is noting preventing us form using focal at this point right
18:01:49 dansmith lyarwood: okay, we can wait if it's significant, but I think we should aim to do it
18:01:50 lyarwood dansmith: I guess, it's just not as stable as the focal based job at the moment imho
18:02:00 sean-k-mooney it was only using bionic for the device detach thing
18:02:09 sean-k-mooney which is kind of fixed with the increased timeout
18:02:24 lyarwood sean-k-mooney: it's the move to the native zuulv3 based job that's blocking us at the moment
18:02:26 dansmith lyarwood: if we run both and the superset is less stable, it's the same number of -1s from zuul, but double the resource usage, so :/
18:02:27 gmann lyarwood: yeah bionic and zuulv2
18:02:29 sean-k-mooney and which gibi is trying to fix fully currently usign the events
18:02:51 gmann dansmith: but to stop the grenade-py3 we need to change in integrated-gate template also
18:02:52 lyarwood sean-k-mooney: that isn't the issue anymore
18:02:54 sean-k-mooney lyarwood: right but it could be zuulv2 + focal
18:03:07 sean-k-mooney you just need to change the label
18:03:34 lyarwood sean-k-mooney: assuming devstack-gate etc actually support it
18:03:36 gmann dansmith: here https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L378
18:03:39 lyarwood I'm not sure that's the case
18:04:04 gmann sean-k-mooney: its not easy, legacy jobs were left to run on bionic and once they move to zuulv3 it will run on focal
18:04:19 gmann so how much work we need for Focal in devstack-gate is not known
18:04:28 sean-k-mooney gmann: devstack-gate basiclaly wraps devstack i dont think its actully executing os level commands
18:04:30 dansmith gmann: right that's where we inherit it from, correct? we have to do something in nova/.zuul to say "don't run this" ?
18:05:04 lyarwood FWIW I wanted to help move the multinode grenade job to zuulv3 once https://review.opendev.org/q/topic:%2522native-zuulv3-migration%2522+owner:lyarwood%2540redhat.com+status:open had landed for nova-live-migration-ceph
18:05:24 lyarwood ^ that's pretty much ready now I think, just needs core reviews in devstack, devstack-plugin-ceph and eventually nova.
18:05:25 gmann dansmith: i do not think there is a way to say "don't run this". we have to remove it from defined pipeline from template or explicitly added
18:06:04 dansmith gmann: ah, what if we set irrelevant files to "everything" ?
18:06:17 gmann lyarwood: yeah, I need to look into this patch to proceed further https://review.opendev.org/c/openstack/nova/+/742056
18:07:25 gmann dansmith: :) that is nice trick but let's remove it from template so that grenade testing can be added explicitly by projects with base or specific jobs
18:07:58 dansmith gmann: okay I just didn't want to mess with the base template and/or make everyone add grenade themselves
18:09:25 gmann dansmith: integrated-gate-compute is used by nova only so it is fine.
18:09:32 dansmith ah
18:09:56 gmann and we will keep it in integrated-gate so that it can used as complete set of integration + upgrade tests
18:10:07 dansmith oh I see, -compute
18:10:08 dansmith got it
18:10:23 dansmith gmann: I will propose and we can -W until we do the conversion
18:10:46 gmann yeah, i separated those template per integrated services so that we can do such type of optimization
18:10:52 gmann +1
18:11:01 dansmith gmann: you're smart :)
18:11:46 gmann otherwise nova and neutron use to get swift failure and cinder get neutron and vice versa
18:14:15 rouk 2.48 removed lots of kvm details (specifically memory) when standardizing diagnostics, i can get more detail by asking for 2.47, where are these details represented in 2.48+?
18:19:00 sean-k-mooney why are we altering the templates by the way.
18:19:20 sean-k-mooney given grenade and the multi node one are both listed in our .zuul.yaml in the check pipeline
18:19:45 sean-k-mooney https://github.com/openstack/nova/blob/master/.zuul.yaml#L443-L470
18:20:09 sean-k-mooney given noone else use integrated-gate-compute
18:20:22 sean-k-mooney im not sure moving grenade into that nessisarly helps
18:22:00 sean-k-mooney im not sure maintianing https://opendev.org/openstack/tempest/src/branch/master/zuul.d/integrated-gate.yaml#L369-L383 makes sense
18:22:22 sean-k-mooney at least im not sure it should live in tempest
18:22:52 gmann sean-k-mooney: it need to be at central place in QA side.
18:22:59 sean-k-mooney same for the other project for that matter
18:23:07 sean-k-mooney i dont really thing it does
18:23:37 gmann this can be extended in future to add slow test job too which is currently not separated out as such
18:24:10 sean-k-mooney it could but since we would want the project input when doing that
18:24:18 sean-k-mooney does it not make sense to defien it in the proejcts
18:24:52 gmann its both project and QA
18:25:45 sean-k-mooney right but it feels odd that tempest would reference any job not defiend in it in that template
18:27:28 sean-k-mooney gmann: if dansmith is ok with it i guess its fine it just feels odd that the qa team would be defining jobs that run against nova outside of the nova repo
18:27:43 dansmith tons of jobs are like that?
18:27:51 dansmith we define jobs other projects run
18:28:06 sean-k-mooney well i dont know tha tfeels more elective
18:28:19 sean-k-mooney i guess its just greneade the feels weried to me
18:28:22 sean-k-mooney i dotn know why
18:28:34 sean-k-mooney i know all the tox jobs work this way
18:28:53 sean-k-mooney i just wasnt expecting to see grenade in those templates
18:29:35 sean-k-mooney since that was managed in tree by project grenade supported
18:30:44 sean-k-mooney for example neutron https://github.com/openstack/neutron/blob/master/zuul.d/project.yaml#L21-L22
18:32:15 sean-k-mooney although they do not use integrated-gate-networking
18:33:41 sean-k-mooney gmann: ignore me ill get used to it
18:34:07 gmann neutron has done this changes due to the such optimization only like multiple grenade jobs running
18:34:23 gmann template help in long term when we extend it to cover the common things.
18:34:51 sean-k-mooney im not sure what else you would add
18:35:20 gmann slow job is one in list which should be optimize per integrated service and run on gate
18:35:38 sean-k-mooney if this was a PTI template or something sure but this partly feels like a resstion to defining everything in the project_config repo
18:35:39 gmann integrated-gate-compute does not cover all the tempest tests
18:35:58 sean-k-mooney gmann: yes but im not sure we want it too
18:36:14 sean-k-mooney if we did we would need to test multipel storage backend for example
18:36:15 gmann overall idea is have a common template which can cover all the related tests (which might be in different jobs due to requried configuration)
18:36:26 sean-k-mooney so we would need at least 2 jobs running full tempest
18:36:55 gmann 'full tempest' cannot be covered by two jobs. full name is confusing there always :)

Earlier   Later