| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-12 | |||
| 14:13:12 | hansmoleman | you want to start in the clean target first and then cherry pick (backport) to nova | |
| 14:13:26 | hansmoleman | but what do i know | |
| 14:16:21 | hansmoleman | SteelyDan: re our conversation the other day about attaching volumes while resized, apparently it's fine once you revert, the volume attached while the server is in VERIFY_RESIZE state continues to be attached when you revert | |
| 14:16:30 | hansmoleman | now, i'm using the fake driver in devstack so i can have 2 computes on a single node, | |
| 14:16:42 | hansmoleman | so i'm not sure that attached volume is actually still in the guest... | |
| 14:17:06 | SteelyDan | hansmoleman: ugh | |
| 14:17:39 | hansmoleman | i don't have a 2-node devstack with libvirt handy | |
| 14:21:55 | fried_rice | hansmoleman: I guess if you want to be that strict about it, sure. But which would you merge first? The nova side so you can test it fully? | |
| 14:22:23 | hansmoleman | as in devstack runs? | |
| 14:22:42 | hansmoleman | that probably makes more sense... | |
| 14:23:11 | fried_rice | Okay. | |
| 14:23:55 | hansmoleman | cfriesen: do you guys care about this? https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens+topic:bug/1746393 | |
| 14:24:02 | fried_rice | hansmoleman: To drop a placement fix at this point, you need to propose it to both the nova and placement repositories with the same change-id, but merge the nova side first. | |
| 14:24:06 | fried_rice | There, it's official. | |
| 14:25:37 | hansmoleman | it's not official until it's engraved in stone tablets | |
| 14:25:47 | sean-k-mooney | fried_rice: so for https://review.openstack.org/#/c/610034/ i need to just cherrypick it ot placement too | |
| 14:26:53 | fried_rice | sean-k-mooney: afaik there's no actual cherry pick between different repositories. But in spirit, yes. | |
| 14:27:11 | fried_rice | sean-k-mooney: And -W it until ^ merges. | |
| 14:27:15 | sean-k-mooney | fried_rice: you have to manually add the other repo as a remote | |
| 14:27:38 | hansmoleman | finucannot: i guess i still feel that backport is really more about a feature than a bug | |
| 14:27:44 | hansmoleman | it's an optimization thing isn't it? | |
| 14:27:50 | sean-k-mooney | if placement was extracted correctly with its git history it shoudl work but ya | |
| 14:28:13 | hansmoleman | i.e. when cpu pinning was added, or emulator thread policy, people didn't think about them being used together all the way, so it was less optimal, | |
| 14:28:17 | hansmoleman | and that's fixed since rocky | |
| 14:28:22 | hansmoleman | but doesn't mean we need to backport that to queens | |
| 14:28:22 | fried_rice | sean-k-mooney: Having them under the same change-id ought to be sufficient. If you included the commit hash, you would have to also include the repo name for that commit. | |
| 14:28:49 | fried_rice | sean-k-mooney: But they won't match exactly, if for no other reason than the file names. | |
| 14:29:13 | sean-k-mooney | fried_rice: right | |
| 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 | |