| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 13:20:03 | efried | mriedem: wrong link for mgagne's thing? | |
| 13:20:20 | mriedem | yes... | |
| 13:20:27 | mriedem | https://review.openstack.org/#/c/580742/ | |
| 13:28:28 | gibi | mriedem_afk: besides the question in https://review.openstack.org/#/c/434870/37/nova/tests/unit/compute/test_compute_mgr.py@182 I'm +2 | |
| 13:29:23 | bauzas | mriedem_afk: ack, sorry was away | |
| 13:31:19 | mgagne | mriedem_afk, melwitt: if you feel the multi fixed-ips spec needs more work, I don't mind postponing to the next release. I want to make sure all concerns are addressed before implementing it. | |
| 13:45:33 | bauzas | mriedem_afk: dansmith: humpf, I'm torn by https://review.openstack.org/#/c/434870/37/nova/compute/manager.py@1054 | |
| 13:53:09 | melwitt | nova meeting in 7 minutes | |
| 13:53:22 | mriedem_afk | gibi: looking | |
| 13:53:39 | mriedem | mgagne: i approved the spec update | |
| 13:54:12 | mriedem | bauzas: the lazy load thing can be done in the follow up patch right? if we care about that. | |
| 13:55:25 | mriedem | gibi: you're right, good eye | |
| 13:55:26 | melwitt | mgagne: I think it's okay, just wanted to sanity check the 'networks' and 'services' part with dansmith | |
| 13:55:54 | dansmith | mriedem: I think the lazy-load thing is important to fix, personally | |
| 13:56:13 | dansmith | melwitt: link? | |
| 13:56:34 | dansmith | mriedem: I'm having a hard time with encoding this level of libvirtness into that manager-level event handler | |
| 13:56:36 | mriedem | dansmith: gibi: bauzas: ok i'll fix the lazy-load thing to make it conditional and fix that unit test | |
| 13:56:37 | melwitt | dansmith: https://review.openstack.org/#/c/580742/4/releasenotes/notes/multiple-fixed-ips-network-information-e2eabb992b7c1e33.yaml@9 | |
| 13:56:51 | mriedem | dansmith: that's the way this compute manager thing has kind of always been | |
| 13:56:54 | bauzas | mriedem: ack | |
| 13:56:57 | dansmith | mriedem: If you'll do it afterwards I'm okay with that, but I do think it needs to be fixed | |
| 13:57:00 | mriedem | the only other driver that uses the callback is the hyperv driver i think | |
| 13:57:14 | mriedem | i would prefer handling the lazy-load in the follow up if possible given the gate | |
| 13:57:17 | dansmith | mriedem: yes, hyperv does, and I know, but.. this is next level invasiveness | |
| 13:57:27 | mriedem | i don't know what alternative we'd have | |
| 13:57:45 | mriedem | but i do know this works in the post-copy trigger, it shows up in the n-cpu logs in the next patch in the series in the live migration job | |
| 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 | |