| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 13:57:52 | dansmith | I don't understand why we need this handler to know about both of these states | |
| 13:59:06 | gibi | mriedem: I have one thing to consider in the next patch in that series as well https://review.openstack.org/#/c/522537/35/nova/conductor/tasks/live_migrate.py@279 | |
| 14:00:49 | dansmith | o/ | |
| 14:00:51 | dansmith | oops :) | |
| 14:02:48 | mriedem | gibi: replied | |
| 14:03:15 | mriedem | dansmith: replied about instance.migration_context - answer is 'no' because that's only set during claims which we don't do for live migration | |
| 14:03:46 | dansmith | ugh | |
| 14:04:10 | mriedem | that might change with artom's numa-aware live migration stuff, idk | |
| 14:04:29 | artom | mriedem, that's not the plan currently | |
| 14:04:53 | artom | I'd rather just wait/help NUMA in placement along, so we can handle allocations there | |
| 14:07:11 | gibi | mriedem, dansmith: thanks for the explanation about the behaviour of setting a non ovo field. I'm +2 now | |
| 14:08:16 | mriedem | gibi: thanks | |
| 14:24:26 | dansmith | mriedem: so, just spitballing, | |
| 14:24:52 | dansmith | but we could just assign the migration context to the instance in live_migrate when we create the migration to make it easier for everything that needs this | |
| 14:25:03 | dansmith | this isn't the first time we've needed the context and couldn't get it for live migration | |
| 14:26:45 | mriedem | that's not really a change i want to mess with in the 11th hour | |
| 14:27:42 | kashyap | Hi folks, can anyone remind me how to re-run the 'nova-live-migration' CI job? I don't want to do a blind recheck to not waste CI resources. | |
| 14:27:53 | dansmith | mriedem: no, not saying we should | |
| 14:30:00 | mriedem | kashyap: you ask this same question at least once per month | |
| 14:30:04 | mriedem | you can't just recheck specific jobs | |
| 14:30:08 | mriedem | that defeats the purpose of co-gating | |
| 14:30:15 | kashyap | Ah, I just remembered that | |
| 14:30:21 | kashyap | Sorry, goldfish like memory | |
| 14:30:33 | kashyap | And the goddamned 37C heat isn't helping | |
| 14:31:45 | mriedem | you're gonna have to speak F around these parts | |
| 14:31:55 | dansmith | veryhotF | |
| 14:32:22 | kashyap | Hehe, ~97F | |
| 14:32:48 | kashyap | More closer to 99F, actually. | |
| 14:40:36 | mriedem | psh | |
| 14:41:03 | kashyap | Not sure how high it goes there in Minnesota | |
| 14:45:10 | mriedem | the level of passive aggressive in MN is off the charts, if that helps | |
| 14:46:45 | kashyap | Hehe | |
| 14:47:42 | efried | We've had several triple-digit days over the past week. | |
| 14:51:05 | mriedem | it's like 100F+ across the board in china | |
| 14:51:14 | dansmith | kashyap: it gets well over 100F in oregon all the time | |
| 14:51:25 | mriedem | i'll be over there in 2 weeks in short shorts, flip flops and a belly t | |
| 14:51:31 | dansmith | mriedem: I left some very non-passive aggressive comments in that patch, let me know what you think | |
| 14:53:00 | bauzas | dansmith: your comment is understandable :) | |
| 14:53:18 | mriedem | wfm, and i don't disagree | |
| 14:53:47 | mriedem | i'd think a different callback would be in order which only the libvirt driver would implement for this, but idk | |
| 14:53:58 | bauzas | mriedem: the problem I have with this change is that's a big one and I'm not really a big expert on it | |
| 14:54:01 | dansmith | yeah, something in virtapi | |
| 14:54:17 | dansmith | should be fairly trivial to implement | |
| 14:54:18 | bauzas | mriedem: so, +Wing it means a lot of time for me to make sure | |
| 14:54:20 | mriedem | i will add a todo in the follow up to explore options to extract this into it's own thing | |
| 14:54:31 | mriedem | bauzas: let gibi +W i then :) | |
| 14:54:33 | mriedem | *it | |
| 14:54:35 | dansmith | mriedem: you can TODO(dansmith) it if you want | |
| 14:54:46 | bauzas | if gibi is fine with it... | |
| 14:54:58 | bauzas | I just want to be honest | |
| 14:55:05 | bauzas | (and FWIW, 38°C here) | |
| 14:55:11 | bauzas | (and I can't swim !) | |
| 14:56:57 | mriedem | gibi: ok to +W and then i'll fix the test(s) in the follow up patch? https://review.openstack.org/#/c/434870/ | |
| 14:57:30 | mriedem | god stephen's bottom change hasn't even made it through the gate yet | |
| 14:57:41 | dansmith | I know | |
| 14:58:42 | mriedem | gmann: so i don't know why we don't just have a tempest-slow job | |
| 14:59:00 | mriedem | looking at https://review.openstack.org/#/c/567697/1/playbooks/legacy/nova-slow/run.yaml@26 | |
| 14:59:16 | mriedem | what i had originally proposed as a compute-specific job that would run only compute api and scenario tests marked slow | |
| 14:59:20 | mriedem | *was a | |
| 14:59:55 | gmann | mriedem: just commented on patch. i thought of giving try to run all sceanrio tests in parallel which tempest-full does not do | |
| 15:00:24 | gmann | but yes, running scenario tests twice is not good way. | |
| 15:01:06 | gmann | i can make tempest-scenario-all job to slow job only and bring back the scenario tests running as parallel in tempest-full as end goal. | |
| 15:01:49 | mriedem | why do we need to tinker with tempest-full at all? | |
| 15:01:55 | mriedem | leave that alone, | |
| 15:02:01 | mriedem | add a tempest-slow job that just runs slow tests | |
| 15:02:03 | mriedem | the end | |
| 15:02:42 | mriedem | tempest-slow could run slow scenario tests concurrently, that doesn't matter to me | |
| 15:02:47 | gmann | but we should run scenario tests in parallel somewhere. making tempest-full to run scenario tests as serial was temporary work around | |
| 15:02:56 | mriedem | but i thought the reason for running scenario tests in serial was more about random failures than it was overall time | |
| 15:03:14 | mriedem | work around for what? | |
| 15:03:17 | gmann | yeah ssh timeout mainly | |
| 15:03:24 | mriedem | ok, | |
| 15:03:28 | mriedem | as far as i know, that's not fixed | |
| 15:03:38 | mriedem | so the workaround would need to be in place | |
| 15:04:02 | mriedem | but imo it shouldn't block adding a purely tempest-slow job that is the same as tempest-full except it runs slow tests | |
| 15:04:10 | pooja_jadhav | mriedem: Hello, need some help | |
| 15:04:29 | gmann | yeah, i am not saying changing that now but if we move scenatio-slow to run only slow then at some point we need scenario parallel testing | |
| 15:05:24 | gmann | "tempest-slow job that is the same as tempest-full except it runs slow tests" - you mean tempest-slow will run all tests including slow? | |
| 15:05:34 | mriedem | ONLY slow | |
| 15:05:39 | gmann | ok. | |
| 15:05:48 | pooja_jadhav | mriedem: If I am doing live migrate, my both nodes(source, destination) referring to nfs shared storage then it should not shh to the destination node. but its going for ssh. | |
| 15:06:06 | gmann | mriedem: make sense. | |
| 15:06:21 | mriedem | gmann: that's what i originally proposed in the ML thread | |
| 15:06:27 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-May/130394.html | |
| 15:07:19 | gmann | mriedem: ok, ll re iterate that job and update patch. but after rocky | |
| 15:10:24 | mriedem | o/ | |
| 15:20:56 | dansmith | gibi: want to hit this? https://review.openstack.org/#/c/434870/ | |
| 15:20:57 | gibi | mriedem: I'm +Wing the bottom... | |
| 15:21:30 | gibi | dansmith, mriedem: +W | |
| 15:21:42 | dansmith | thanks | |
| 15:21:53 | mriedem | thanks | |
| 15:22:05 | dansmith | what else needs attention on that set? | |
| 15:22:14 | dansmith | gerrit seems kinda confused | |
| 15:22:14 | mriedem | i need to update the nits patch | |
| 15:22:16 | mriedem | was just looking at that | |
| 15:22:22 | dansmith | is that it? | |
| 15:22:26 | mriedem | yeah | |
| 15:22:30 | dansmith | alright | |
| 15:22:32 | mriedem | once https://review.openstack.org/#/c/522537/ merges it's bp complete | |
| 15:22:56 | dansmith | okay | |