| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-16 | |||
| 21:12:27 | mriedem | the CellDatabase fixture has a default of cell1 so the stuff probably just gets created there | |
| 21:12:40 | mriedem | sean-k-mooney: also btw i added https://review.opendev.org/#/c/670585/2 to https://review.opendev.org/#/c/670585/2 https://etherpad.openstack.org/p/nova-train-release-todo | |
| 21:12:43 | mriedem | so we don't forget | |
| 21:13:36 | sean-k-mooney | ok cool thanks. it would not be the end of the world if it sliped but im hopeing that we can drop supprot for this downstream before our next LTS | |
| 21:14:02 | sean-k-mooney | so in 24-18 months when people start using it we dont have to support it | |
| 21:15:20 | artom | sean-k-mooney, are you really though? :P | |
| 21:15:42 | sean-k-mooney | only by the expect it to work and get new features bit | |
| 21:16:01 | sean-k-mooney | they can choose one but not both if they want something that old | |
| 21:17:05 | mriedem | they expect you to make it work and provide new features when they shovel out the $$$ to your sales guys | |
| 21:17:07 | mriedem | and gals | |
| 21:17:22 | mriedem | and then the shit rolls down hill to you, the developer | |
| 21:18:21 | sean-k-mooney | ya well we try to do both but when you cant backport api,db or object changes addinf features that arent bug fixs to old release is | |
| 21:18:25 | sean-k-mooney | challanging | |
| 21:19:56 | efried | mriedem: I don't see anywhere we start cell conductor services. What would that look like? | |
| 21:20:08 | efried | Or do we do it implicitly when we start a compute service in a specific cell? | |
| 21:20:55 | sean-k-mooney | if we are starting only one conductor the we are running it in the non super conductor toplogy | |
| 21:21:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Only allow one scheduler service in tests https://review.opendev.org/682486 | |
| 21:21:31 | sean-k-mooney | i dont know if we create multiple conductors in the current fucntional test but the cross cell migration code might have some? | |
| 21:22:40 | efried | we don't have any cross-cell migration code | |
| 21:22:47 | efried | tssssssss | |
| 21:23:31 | sean-k-mooney | i ment there might be case in mriedem series | |
| 21:24:42 | sean-k-mooney | we might be relying on https://github.com/openstack/nova/blob/master/nova/tests/functional/integrated_helpers.py#L118 | |
| 21:24:55 | mriedem | efried: we don't do the whole super conductor / cell conductor thing in functional tests | |
| 21:24:57 | mriedem | it's all just one | |
| 21:24:58 | sean-k-mooney | to start the conductor in the functional test | |
| 21:25:06 | mriedem | efried: meaning we get away with shit in functional tests that we wouldn't in devstack | |
| 21:25:47 | mriedem | e.g. we do stuff like have the CheatingSerializer so it all looks like one RPC | |
| 21:25:54 | sean-k-mooney | i think devstack has the abiltiy to deploy in the legacy mode too but i dont know if thats tested still so it could be broken | |
| 21:25:58 | mriedem | which has been a problem in my cross-cell series with functional tests | |
| 21:26:10 | mriedem | sean-k-mooney: all grenade jobs are non-superconductor | |
| 21:26:39 | sean-k-mooney | ah ok. is that still true for the new zuulv3 version? | |
| 21:27:07 | mriedem | i would expect so but haven't looked | |
| 21:27:22 | sean-k-mooney | i tried using that to do a greade version of my numa jobs but i found i could not set local.conf diffrently for new/old nodes | |
| 21:27:25 | sean-k-mooney | localrc yes | |
| 21:27:29 | sean-k-mooney | but not local.conf | |
| 21:27:41 | sean-k-mooney | so i could not do the config overrides i needed | |
| 21:28:20 | sean-k-mooney | to be fair i dont know if normal greande supports that but it was something i found when i treid to use it | |
| 21:37:25 | sean-k-mooney | mriedem: by the way im going to spend some time this week trying to refine the nfv job into something we can have more permentaly and aslo creating an ovs-dpdk job. is this something we would consider merging before RC1 or shoudl i target U with the hope of maybe backporting. | |
| 21:38:04 | sean-k-mooney | initally i want to run them as periodic jobs/via experimental but if i get multiple provider i would like to consier addign them to check if they seam stable | |
| 21:38:45 | mriedem | i would say don't get the cart (backports) before the horse (actually getting something working on master) | |
| 21:39:33 | sean-k-mooney | well i had a dpdk job working w while ago then it broke because fedora | |
| 21:39:35 | sean-k-mooney | https://review.opendev.org/#/c/656580/ | |
| 21:40:10 | sean-k-mooney | and the nfv job works. but i want to get them working properly before going anywher near nova check | |
| 21:40:20 | sean-k-mooney | hence start with a nightly periodic job | |
| 21:46:28 | efried | mriedem: any chance of nailing down test_walk_versions this week? | |
| 21:47:49 | mriedem | efried: i lost track of that | |
| 21:48:02 | mriedem | weren't you trying to pull the mysql logs or something for debug? | |
| 21:48:18 | efried | yeah, I think I eventually succeeded in doing that but they didn't show anything interesting. | |
| 21:48:50 | efried | mriedem: https://review.opendev.org/#/c/678051/ | |
| 21:49:11 | sean-k-mooney | look like the pcpu reshap went into merge conflict with somehting | |
| 21:50:31 | efried | mriedem: the bad one has this additional message https://zuul.opendev.org/t/openstack/build/f9b92d66ade145a195b996708cd66c28/log/mysql/error.log#202 | |
| 21:50:31 | efried | and a few more of the final 'Aborted connection' lines | |
| 21:50:35 | efried | but otherwise they look the same to me. | |
| 21:50:43 | efried | sean-k-mooney: what makes you say that? The yellow dot? | |
| 21:50:57 | efried | oh | |
| 21:51:00 | sean-k-mooney | no the "Patch in Merge Conflict" | |
| 21:51:02 | efried | well wtf | |
| 21:51:18 | efried | nothing has merged lately | |
| 21:51:30 | sean-k-mooney | we merged a few patches like an hour ago | |
| 21:51:40 | mriedem | i've noticed sometimes gerrit will say something is in merge conflict and then i have a triviall conflict-free local rebase | |
| 21:52:08 | sean-k-mooney | proably the service wide pause thing | |
| 21:52:22 | sean-k-mooney | ya | |
| 21:52:56 | sean-k-mooney | shall i pull it down and rebase against master? | |
| 21:53:08 | efried | no | |
| 21:53:12 | sean-k-mooney | ok | |
| 21:53:18 | efried | then we lose all of our +Vs on the rest of the series. | |
| 21:53:41 | efried | Next time a bottom one fails in the gate and -2s the whole pile, maybe we can do that. | |
| 21:53:53 | sean-k-mooney | i was just about to check that | |
| 21:54:10 | efried | mriedem: So should we be getting all those "Aborted connection" things in the first place? | |
| 21:54:20 | mriedem | efried: that i don't know | |
| 21:54:22 | efried | does that mean we're not shutting down the db gracefully? | |
| 21:54:31 | efried | and regardless, should that matter? | |
| 21:54:38 | mriedem | the wacky names are just the random db names | |
| 21:54:45 | sean-k-mooney | there are not patches in the gate for nova. they are all in check. but ill leave it wait till the morning | |
| 21:54:45 | efried | is this a job for zzzeek? | |
| 21:55:08 | mriedem | idk about that, but zzzeek might be able to tell us what to turn on for debugging | |
| 21:55:37 | efried | sean-k-mooney: right, about 12 of the 15 patches have cleared the check queue at this point. The bottom one is waiting; once it completes, the whole swatch will get shoved into the gate pipeline. | |
| 21:55:42 | mriedem | we're also using some deprecated opportunistic db test fixture stuff from oslo.db and i don't know if moving off the deprecated stuff would help us | |
| 21:55:59 | efried | mriedem: well, couldn't hurt. What are you talking about specifically? | |
| 21:56:54 | mriedem | it's been awhile since i looked, sec | |
| 21:57:07 | sean-k-mooney | ya ok then let hold off untill the patches below it have merged | |
| 21:57:23 | efried | sean-k-mooney: and tbh I'm not super worried about a merge conflict on that 15th patch. We've got at least a dozen rechecks to go before we get there. | |
| 21:58:01 | sean-k-mooney | ... hopefully not but we do need to kill some of the random failures | |
| 21:58:21 | efried | well hopefully we killed two of them today | |
| 21:58:42 | sean-k-mooney | ya and mriedem killed 1?2? yesterday | |
| 21:58:52 | efried | I took a couple of samples this morning and determined that the Nth patch takes ~N rechecks to merge. | |
| 21:58:54 | sean-k-mooney | firday i cant rememebr | |
| 21:59:10 | sean-k-mooney | :( | |
| 21:59:35 | efried | mriedem: test_fixtures.PostgresqlOpportunisticFixture and test_fixtures.MySQLOpportunisticFixture ? | |
| 22:00:04 | mriedem | efried: was fixed already https://review.opendev.org/#/c/609352/ | |
| 22:01:08 | efried | okay | |
| 22:02:53 | sean-k-mooney | mriedem: by the way i got an error running the sql migate unit tests http://paste.openstack.org/show/776829/ | |
| 22:03:21 | sean-k-mooney | given the rest passed im going to push this soon but shoudl tox not install that | |
| 22:03:29 | sean-k-mooney | i guess it could have moved | |
| 22:04:50 | sean-k-mooney | i assume ibm_db_sa is a sqlalcheme pluging for ibm db backend and its just not installled by tox for some reason | |
| 22:05:30 | mriedem | umm, that should just be skipped | |
| 22:06:12 | mriedem | well, or, | |
| 22:06:36 | mriedem | tox should have pulled it in https://github.com/openstack/sqlalchemy-migrate/blob/master/test-requirements-py2.txt#L1 | |
| 22:06:49 | sean-k-mooney | the py27 version allso requries me to install the mysql hearder to compile the client... | |
| 22:06:53 | mriedem | https://github.com/openstack/sqlalchemy-migrate/blob/master/test-requirements-py3.txt#L1 | |