Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-12
14:30:52 sean-k-mooney hansmoleman: we may backport it downstram but it depens i dont think we need to backport to queens upstream
14:31:00 finucannot hansmoleman: Not sure, to be honest. Guess that comes down to interpretation
14:31:30 sean-k-mooney the downstream but was reported against rocky so that is likely all that would be useful to backport to in anycase
14:31:55 hansmoleman i've -1ed the bottom queens backport then
14:31:59 hansmoleman if you want my official opinion
14:32:12 finucannot Heh. Fair :)
14:32:19 sean-k-mooney hansmoleman: wait which patch
14:32:25 hansmoleman https://review.openstack.org/#/c/588570/
14:33:00 sean-k-mooney oh i was talking about the placement one im not sure about that one
14:33:08 hansmoleman too late
14:33:14 hansmoleman you said red hat doesn't care so i get to -1
14:33:41 SteelyDan reading the bug, that seems like a performance feature to me
14:33:57 SteelyDan is there some correctness aspect to it, or purely optimized layout/
14:34:38 openstack Launchpad bug 1744965 in OpenStack Compute (nova) "'emulator_threads_policy' doesn't work with 'vcpu_pin_set'" [Undecided,Fix released] - Assigned to Stephen Finucane (stephenfinucane)
14:34:38 sean-k-mooney this bug https://bugs.launchpad.net/nova/+bug/1744965 just reading
14:35:02 openstack bugzilla.redhat.com bug 1534669 in openstack-nova "emulator_threads_policy needs improvement when hyper threading is enabled" [Medium,On_qa] - Assigned to sfinucan
14:35:02 finucannot The BZ that was based on is probably more useful https://bugzilla.redhat.com/show_bug.cgi?id=1534669
14:35:27 finucannot (see comment 1. That's a bug, IMO)
14:36:21 sean-k-mooney finucannot: what was your fix to just give both thread spiblivgs to the emultor threads
14:37:14 finucannot sean-k-mooney: Nah. We stopped applying the vCPU policies to emulator threads
14:37:50 sean-k-mooney finucannot: the polices dotn change teh number of thread you get pinned too howerver
14:38:43 finucannot They kind of do. isolate doesn't cause the VM to consume more cores but the thread siblings are marked as unusable
14:39:12 sean-k-mooney that is different
14:39:50 sean-k-mooney if the vcpu_pin_set has 6 cores and you request a vm with 6 vcpus and 1 emulator thread it should not be shcudled to that host as it cant fit
14:39:59 finucannot Correct
14:40:19 finucannot If vcpu_pin_set has 7 cores though, it should be scheduled
14:40:27 sean-k-mooney yes
14:40:49 sean-k-mooney so what is the bug
14:41:00 finucannot We actually needed 8
14:41:15 sean-k-mooney why
14:41:17 finucannot because the policy meant for vcPUx was being incorrectly applied to emulator threads
14:41:30 finucannot *vCPUs
14:41:47 sean-k-mooney even if we applied it it should not matter what thread policy would chage it
14:41:58 finucannot huh?
14:42:19 sean-k-mooney isolate is not meant to consider thread outside of the vcpu_pin_set so even if you have hyper threading it should not be an issue
14:43:21 finucannot Exactly, but the implementation was buggy
14:44:28 finucannot It was saying "because we're using pairs of thread siblings for these vCPUs, we should do that for emulator threads too"
14:45:09 sean-k-mooney finucannot: ok ya that is wrong. is thei your change to handeling differnet lent sibling sets
14:45:43 finucannot So if you were using the require policy, that would require two cores for emulator threads (the latter wasn't use though, I think)
14:46:13 openstackgerrit Chuck Short proposed openstack/os-traits master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610065
14:46:32 sean-k-mooney you are intended to be able to ask for 1 core and say threading policy require
14:46:43 finucannot Yup, that was broken too
14:47:07 sean-k-mooney you are alos ment to be able to use prefer on host that dont have hyper threading
14:47:55 finucannot yep
14:49:33 sean-k-mooney finucannot: so if we backported it to queens are you also going to backport it to pike
14:49:53 sean-k-mooney finucannot: that is where the downstream bug was reported
14:50:10 openstackgerrit Chuck Short proposed openstack/os-vif master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610068
14:50:10 finucannot I'd like to but you've to do one before the other
14:50:34 hansmoleman persisting limits and requested_destination in a request spec seems like a bad idea... http://paste.openstack.org/show/731972/
14:52:27 openstackgerrit Jose Castro Leon proposed openstack/nova master: Fix get_device_path from network mounted volume https://review.openstack.org/590188
14:53:39 sean-k-mooney finucannot: so i dont think there is anything harmful in the backport so i guess its fine but im not sure it qualifes under the backport policy
14:54:11 finucannot Yup, seems to be the general consensus, heh
14:55:11 sean-k-mooney queens would be pahse 2 right so its not a security fix and its not a critical prioity bug https://docs.openstack.org/murano/pike/contributor/stable_branches.html
14:55:26 sean-k-mooney oh thats mruanos one...
14:55:39 finucannot sean-k-mooney: https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
14:56:22 sean-k-mooney oh ya they changed the with extended maintaince
14:58:19 melwitt hm, why isn't the nova-lvm job running anymore...
14:58:50 melwitt oh nvm, it only runs on libvirt changes
14:59:18 hansmoleman ah yes: cold migrate to a specified host, confirm the resize, then live migrate w/o specifying a host, kablammo
14:59:30 hansmoleman reqspec strikes agin
14:59:33 hansmoleman *again
15:00:53 openstackgerrit Chuck Short proposed openstack/osc-placement master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610074
15:00:55 sean-k-mooney hansmoleman: im guessign we persist a host of somthing that we should have deleted in the confirm step
15:01:34 hansmoleman i know exactly what it is
15:01:37 hansmoleman i just needed to confirm
15:02:17 sean-k-mooney actully for moving py35 to py37 job on stein+ that maeans that the minium version of python for stein becomes 36 right
15:02:38 sean-k-mooney wew would no longer be testing 35 so it cant be the minium anymore
15:02:44 openstackgerrit Stephen Finucane proposed openstack/nova master: Deprecate the nova-console service https://review.openstack.org/610075
15:02:45 openstackgerrit Stephen Finucane proposed openstack/nova master: Deprecate the nova-xvpvncproxy service https://review.openstack.org/610076
15:04:29 cfriesen hansmoleman: we had to modify some of that code due to supporting some other features, so I don't think we'd care about a backport.
15:06:10 openstack Launchpad bug 1797580 in OpenStack Compute (nova) "NoValidHost during live migration after cold migrating to a specified host" [High,Triaged] - Assigned to Matt Riedemann (mriedem)
15:06:10 hansmoleman yippee https://bugs.launchpad.net/nova/+bug/1797580
15:23:57 fried_rice leakypipes: A schema like this? https://review.openstack.org/#/c/579289/12/nova_powervm/virt/powervm/inventory_schema.yaml
15:26:21 hansmoleman huh osc doesn't have instance action CLI support?
15:26:36 SteelyDan hansmoleman: I think it does
15:26:42 SteelyDan pretty sure I was using it the other day
15:26:59 hansmoleman don't see it here https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html
15:27:13 hansmoleman server event list?
15:27:27 hansmoleman oh there it is
15:29:02 hansmoleman ok, and because my live migration fails but the server isn't put into error status, i can't see the fault
15:29:06 hansmoleman so i have to use the instance action list
15:29:23 hansmoleman or the migration status
15:29:32 hansmoleman which probably isn't in osc
15:32:35 sean-k-mooney im going to call it a day early(for me). is there anything i should review before next week?
15:33:00 sean-k-mooney if not i proably wont be on irc until thrudsay
15:39:17 openstack bug 1797580 in OpenStack Compute (nova) "NoValidHost during live migration after cold migrating to a specified host" [High,Triaged] https://launchpad.net/bugs/1797580 - Assigned to Matt Riedemann (mriedem)
15:39:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for bug 1797580 https://review.openstack.org/610088
15:39:18 hansmoleman SteelyDan: to fix ^ i'm thinking we should just not persist the RequestSpec.requested_destination
15:39:25 hansmoleman similar to how we've fixed a few related things
15:39:32 hansmoleman requested_destination should be per operation and not saved
15:39:47 SteelyDan aye
15:41:11 leakypipes fried_rice: yup.
15:41:34 leakypipes fried_rice: but that describes the entire provider descriptor file.
15:42:30 fried_rice leakypipes: That schema describes the entire file as originally designed. I'll mod it to be more generic.
15:43:11 fried_rice and include versioning and whatnot
15:54:25 hansmoleman cfriesen: i asked jackding about this earlier, and just left a comment in https://review.openstack.org/#/c/603844/, but it seems we shouldn't need to list the ports again in that new method to check if there are failed port bindings,
15:54:32 hansmoleman b/c we just refreshed the instance info cache before calling that,
15:54:35 hansmoleman which lists the ports for that server
15:54:45 hansmoleman so if we can just rely on the cache, it's a much less heavy cahnge
15:54:46 hansmoleman *change

Earlier   Later