| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-16 | |||
| 20:52:17 | mriedem | b'2019-09-16 15:10:20,156 INFO [nova.service] Starting scheduler node (version 19.1.0)' | |
| 21:01:13 | efried | mriedem: what was the other bug with the duplicated services? | |
| 21:01:26 | mriedem | duplicated placement fixture | |
| 21:01:27 | mriedem | sec | |
| 21:01:41 | mriedem | https://github.com/openstack/nova/commit/5e1b096894f6de4cfbca254cf74dcfcf56358ea5#diff-5befe429f14247314e6ca487aa4e13bd | |
| 21:02:07 | efried | thank you sir | |
| 21:02:13 | efried | I'm posting a poison patch now | |
| 21:02:23 | mriedem | heh i was just writing my commit message ofr one | |
| 21:02:25 | mriedem | *for | |
| 21:02:30 | efried | oh, no bug for I057a07c8d0b880c8d09fc2e618ce1f7fc885beda ? | |
| 21:02:39 | mriedem | guess not | |
| 21:03:20 | efried | hm, if that one was placement fixture, my fix isn't going to hit it. | |
| 21:03:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Do not allow mutiple nova-scheduler workers https://review.opendev.org/682485 | |
| 21:04:06 | mriedem | efried: ^ is what i was thinking of | |
| 21:04:28 | efried | whoah | |
| 21:04:46 | efried | Mine is way dumber, but more complete, and faster. | |
| 21:05:43 | openstackgerrit | Eric Fried proposed openstack/nova master: Only allow one non-compute service in tests https://review.opendev.org/682486 | |
| 21:05:46 | efried | mriedem: ^ | |
| 21:09:21 | mriedem | you're going to at least have failures on tests that intentionally start multiple api fixtures with different projects and roles (admin vs non-admin, project1 and projec2 for filtering, etc) | |
| 21:10:35 | sean-k-mooney | if we have multi cell tests then those would also fail correct | |
| 21:11:13 | efried | yeah, I guess I thought the cell conductors would have different names, but that doesn't make sense. | |
| 21:11:14 | sean-k-mooney | so we need a way to allow it | |
| 21:11:22 | mriedem | the api/conductor/scheduler services don't get registered in the cell dbs | |
| 21:11:24 | mriedem | so i don't think that matters here | |
| 21:12:03 | mriedem | but i'm also not sure how sophisticated our fixture stuff is to know where to create those services (they should go into cell0 but might not) | |
| 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 | and a few more of the final 'Aborted connection' lines | |
| 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: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 | efried | is this a job for zzzeek? | |
| 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 | |