| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 13:08:02 | mriedem | efried: i think we defer | |
| 13:08:22 | mriedem | we'll be lucky to merge stuff that's already been approved for 24 hours | |
| 13:08:43 | mriedem | this is why i asked the "what if we don't get this done in rocky" question in the ML | |
| 13:09:09 | mriedem | i think it just means the same thing, but in stein - you can't use the new fancy wizbang NRP stuff until you've migrated existing inventory/allocations, right? | |
| 13:09:34 | mriedem | so rather than the migration happening *before* getting to stein, it happens *once* you get to stein | |
| 13:10:39 | efried | mriedem: I think that sounds right. | |
| 13:10:55 | mriedem | melwitt: i think the only client releases today are osc-placement and python-novaclient right? | |
| 13:11:03 | mriedem | the various os-* lib releases were last week | |
| 13:11:10 | efried | mriedem: Obviously any of the bps wanting to do nrp with inventory moves won't happen in Rocky, but that was surely the case anyway at this point. | |
| 13:13:21 | efried | So given that, what can I put my eyeballs on today that will help most? | |
| 13:15:51 | mriedem | efried: i was just going through the bp etherpad https://etherpad.openstack.org/p/nova-rocky-blueprint-status | |
| 13:16:05 | mriedem | i've got 2 functional changes left in the port binding series https://review.openstack.org/#/c/434870/ | |
| 13:16:11 | mriedem | https://review.openstack.org/#/c/566813/ is easy | |
| 13:16:22 | mriedem | needs final +2 for the queued for delete cells v2 stuff | |
| 13:16:38 | mriedem | and then i think we're just rechecking stuff that's already approved | |
| 13:17:15 | efried | I haven't been following the down-cell stuff; am I going to be able to make sense of https://review.openstack.org/#/c/566813/ without context? | |
| 13:18:07 | mriedem | should be able to, commit message explains it - we are just setting a flag on the instance mapping when deleting (or restoring) an instance | |
| 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 | |