Earlier  
Posted Nick Remark
#openstack-nova - 2021-01-19
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 :)
18:37:33 sean-k-mooney no i meen we need two jobs running all tempest test with different config
18:38:17 sean-k-mooney for exmple nova libvirt backed has 3 ways to pass sotrage to a guest so if you wante test all 3 with live migraiton you need basially 2 jobs
18:38:43 sean-k-mooney one with lvm/iscis to test cinder voluems and block stoarge and one with ceph to test qemu driect connect
18:38:53 sean-k-mooney *qemu network stoage

Earlier   Later