Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-26
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
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.

Earlier   Later