Earlier  
Posted Nick Remark
#openstack-nova - 2020-01-22
19:04:19 gmann efried: you can use zuulv3 native base jobs from devstack if you do not want to run tempest
19:04:24 sean-k-mooney well dpdk is not important
19:04:44 sean-k-mooney but you can use a pre-run playbook to create a local.sh file which will create custome flavors
19:04:51 sean-k-mooney e.g. request vtpm
19:04:57 efried gmann: is there a "making a devstack zuulv3 job for dummies" guide somewhere?
19:05:03 sean-k-mooney then you can run standard tempest wtih those falvor to test your feature
19:05:17 sean-k-mooney or a subset of tempest
19:05:47 gmann efried: humm, not guide as such i know but i can link you some example from other project did like Tacker etc
19:05:56 gmann or job description
19:06:21 efried k. I don't trust nova's .zuul.yaml cause I never know when there's a legacy minefield I'm walking into.
19:07:01 gmann 'devstasck' can be used with minimum effort on specific jobs - https://github.com/openstack/devstack/blob/2e45f2c267c9ababdbdfc4c505b329398391c5f9/.zuul.yaml#L352
19:07:35 gmann this is tacker multinode job for their functional testing - https://github.com/openstack/tacker/blob/bdb2d52b3a1b69c58cb2ac6f903380ab8a7bd973/.zuul.yaml#L28
19:08:09 efried oh, so it's still kosher to use run.yaml things
19:08:12 efried that's a relief.
19:08:16 sean-k-mooney yes
19:08:30 KeithMnemonic melwitt. did this change break the patch? it is failing on a live migration thing now https://review.opendev.org/#/c/683008/6..7/nova/tests/unit/compute/test_compute.py
19:08:34 gmann multinode support is in all base jobs of devstack which is based on nodeset used on job
19:08:36 sean-k-mooney by default we leave it out in most of our jobs because its coming from the parent job
19:09:08 melwitt KeithMnemonic: lol no, that's a unit test. the live migration job is failing. we might need to rebase. I'm looking at the failure now
19:09:38 efried melwitt: if it's PyYAML, we're just waiting for https://review.opendev.org/#/c/703735/ to merge
19:09:52 melwitt unit tests run in the openstack-tox-py27 and openstack-tox-py35 jobs
19:10:06 KeithMnemonic ok thank you
19:10:57 melwitt efried: this is stable/pike so I doubt it right? the PyYAML is a new thing?
19:11:11 efried oh
19:11:17 efried I don't know. Is devstack branchless or something?
19:11:25 sean-k-mooney efried: here is an example job i need to go update https://review.opendev.org/#/c/679656/12 but it show you how to create a custom job with custom flavor and run standard tempest test to validate thing
19:11:25 melwitt gah gzipped logs again
19:11:33 sean-k-mooney efried: no devstack is branched
19:11:43 melwitt efried: devstack has branches but tempest is branchless
19:11:53 sean-k-mooney yes ^
19:12:21 efried melwitt: okay, that failure looks different, ignore me.
19:12:40 melwitt how are these old crusty jobs having the friggin gzipped logs, dang
19:12:59 efried thanks sean-k-mooney
19:13:29 efried oh, yeah melwitt, that's going to continue to be a problem I guess, unless we plan to migrate legacy jobs to zv3 on stable. Much sad face.
19:13:44 efried we may have to figure out how to get that turned off in the job itself for stable.
19:13:45 melwitt oh geeez :''''''(
19:13:51 sean-k-mooney am well it should not be
19:13:59 sean-k-mooney oh actully
19:14:05 efried I thought it was an infra-level thing.
19:14:11 sean-k-mooney ya it is
19:14:37 efried so, if we're going to have to figure that out anyway, I guess we might as well do it on master, asap, so we can stop being frustrated at least partially.
19:14:39 sean-k-mooney so we need to modify devstack-gate to stop compressing the logs internally
19:14:46 sean-k-mooney and backport that to stable branches
19:15:18 melwitt isn't that what you did though? it didn't stop the compression for legacy jobs on master
19:15:30 melwitt so even if we backport it, it won't help right?
19:15:33 sean-k-mooney my fix fixed non legacy jobs
19:16:31 sean-k-mooney i intended it to fix both but it seams that devstack gate is compressing them somewhere else too
19:16:36 sean-k-mooney or the legacy jobs are
19:16:43 sean-k-mooney it might not be in devstack gate
19:16:54 melwitt got it
19:17:38 melwitt ok, now to find where this thing is failing LM
19:18:41 sean-k-mooney i have been doing " curl <log url> | zcat | lnav -q"
19:19:45 melwitt that's helpful, thanks
19:21:56 sean-k-mooney melwitt: artom was say you can also to "curl <url> | zless" but i like using lnav to browse logs
19:23:13 melwitt I still haven't gotten around to trying lnav so I'll use zless for now
19:23:47 sean-k-mooney ya if you do try it by default lnav dumps all the logs to std out so the -q is there to stop that
19:24:16 melwitt \:| [instance: 5bca844b-4ca6-4c63-a579-8f00316da019] Instance spawn was interrupted before instance_claim, setting instance to ERROR state
19:24:51 sean-k-mooney am that is new
19:24:59 melwitt yeah, it's new to me
19:25:18 sean-k-mooney does that mean qemu crashed or something?
19:25:25 melwitt no idea
19:25:51 sean-k-mooney well that makes two of us
19:26:34 melwitt I don't expect it's related to the patch, and the patch has been sitting around forever so I wouldn't be surprised if it needs a rebase by now. but the nova-live-migration job is failing pretty consistently on it and so far, for unknown reasons
19:26:58 melwitt rechecked it like 3 times and always fail on nova-live-migration
19:27:59 sean-k-mooney i can take a look at it a bit later. what is the review?
19:28:27 sean-k-mooney once i fix the osp 15 backport im doing ill take a quick look before moveing to osp 13
19:28:30 melwitt sean-k-mooney: it's this one https://review.opendev.org/683008
19:28:56 sean-k-mooney cool i have it open.
19:28:58 melwitt note that it is very old, not rebased since september
19:29:00 artom sean-k-mooney, huh, that's the same thing we saw in whitebox
19:29:25 artom We thought it was because we were restarting nova-compute to change configs
19:29:31 sean-k-mooney melwitt: if you do a rebase via the ui i should not hurt
19:29:39 sean-k-mooney but i dont think that is the issue
19:29:53 sean-k-mooney zuul will do a merge with master so it should basicaly be the same
19:29:56 melwitt yeah, probably worth it to try. it's gonna have to be rebased to merge anyway
19:30:06 melwitt let me do it now
19:30:39 sean-k-mooney well its more or less the same as a recheck and will avoid the merge commit so it wont hurt
19:30:49 sean-k-mooney artom: did you fix it in whitebox?
19:31:07 artom sean-k-mooney, by extending the service restart wait delay
19:31:21 artom Which apparently has nothing to do with it, as we're now seeing the same thing in Nova?
19:31:27 sean-k-mooney we are not restart services in this job
19:31:31 sean-k-mooney actully
19:31:35 sean-k-mooney we might be
19:31:39 openstackgerrit melanie witt proposed openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008
19:31:44 artom Wait, n-l-m?
19:31:46 sean-k-mooney i think we do
19:31:52 sean-k-mooney ya
19:32:03 artom We're changing some configs IIRC
19:32:04 sean-k-mooney i think there is a hack that swaps the storage to ceph or something
19:32:05 artom So yeah, we are
19:32:41 sean-k-mooney i think its in the post run playbook
19:33:07 sean-k-mooney ok its not there
19:33:15 sean-k-mooney its proably in the test hook
19:34:56 sean-k-mooney ya so here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/run_tests.sh#L55-L67
19:35:14 artom Ah, yeah, configure_and_start_nova
19:35:53 artom Are... are we just going to hax a sleep in there? Before the run_tempest call?
19:35:54 sean-k-mooney https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/ceph.sh#L71-L100
19:36:33 sean-k-mooney we could hack a sleep here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/ceph.sh#L114
19:37:26 artom Why in ceph?
19:37:48 sean-k-mooney this is where we restart nova after reconfiguring to use ceph

Earlier   Later