| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 13:18:25 | mriedem | so that if the cell goes down for that instance, we have something in the api db to key off to know if the instance was in the process of being deleted | |
| 13:18:40 | mriedem | the actual down cell handling code will be done in stein | |
| 13:18:49 | mriedem | this is all framework building at this point | |
| 13:19:40 | mriedem | oh and we also have https://review.openstack.org/#/c/566813/ for mgagne's metadata api changes for listing multiple ips/subnets per network attached to the vm | |
| 13:19:42 | efried | k, was gonna ask. Nothing is checking this yet | |
| 13:19:47 | mriedem | efried: right | |
| 13:19:48 | mriedem | so low risk | |
| 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 | |