| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-12 | |||
| 13:52:59 | finucannot | That said, I have no idea how else to mitigate that risk besides the unit tests, manual testing that's already been done and downstream QE we'll be doing for this | |
| 13:54:22 | leakypipes | sean-k-mooney: get with cdent in #openstack-placement since he's got a patch series already that is cleaning up the placement DB stuff. | |
| 13:54:42 | leakypipes | sean-k-mooney: Chris isn't here atm, but just grab him whenevs | |
| 13:56:22 | sean-k-mooney | leakypipes: sure. im likely not going to be working on this till next week. im in munich for new heir orentation from sunday to wednesday so i wont get much done until thrusday | |
| 13:57:10 | leakypipes | ack, no worries. | |
| 13:57:26 | leakypipes | sean-k-mooney: btw, is "new heir orentation" something to do with the royal family? | |
| 13:57:44 | sean-k-mooney | also apparently i joinded redhat 90days ago as of monday. | |
| 13:57:44 | leakypipes | :P | |
| 13:57:53 | leakypipes | sean-k-mooney: congrats! :) | |
| 13:58:54 | PapaOurs | sean-k-mooney: I'm sure you'll love sales talks | |
| 13:59:24 | sean-k-mooney | PapaOurs: apparently we are not ment to bring our laptops to the 2 days of training... | |
| 13:59:41 | PapaOurs | sean-k-mooney: tbh I don't remember mine | |
| 13:59:44 | sean-k-mooney | also i miss octoberfest in munich by a week | |
| 13:59:59 | PapaOurs | I mean, whether I used my laptop | |
| 14:00:10 | PapaOurs | but you'll get a free fedora | |
| 14:00:18 | PapaOurs | hum | |
| 14:00:25 | PapaOurs | looks like we're discussing corp here | |
| 14:00:28 | PapaOurs | shit | |
| 14:00:49 | sean-k-mooney | :) | |
| 14:00:49 | PapaOurs | fortunately, I'm hidden behind my nick | |
| 14:07:04 | fried_rice | hansmoleman: Same fix (as far as possible) with same change-id in both nova and placement | |
| 14:08:08 | melwitt | ||
| 14:10:58 | hansmoleman | fried_rice: does order of repos matter? | |
| 14:11:09 | hansmoleman | placement first so it's not lost after the extraction? | |
| 14:11:28 | fried_rice | I don't think so | |
| 14:11:59 | fried_rice | Like, propose it to both at the same time, but I don't think it matters if one merges first as long as they both merge. | |
| 14:12:47 | hansmoleman | that's kind of weird | |
| 14:12:55 | hansmoleman | if one merges and the other has changes | |
| 14:12:59 | hansmoleman | i think of it like backports | |
| 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 | |