Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-12
13:22:19 leakypipes mriedem: lol. thx moleman.
13:22:34 leakypipes there he is!
13:23:12 hansmoleman https://deadhomersociety.files.wordpress.com/2016/11/thisisaknife.gif?w=655
13:24:27 hansmoleman gmann: do you have a patch to cap max microversions for tempest in devstack for rocky yet?
13:25:30 hansmoleman nope, i'll do that
13:30:17 openstackgerrit sean mooney proposed openstack/nova master: harden placement init under wsgi https://review.openstack.org/610034
13:33:35 sean-k-mooney ^ that may be dumb but its my attempt to fix part of a downstream bug in triplo that i dont have an enviornment to reproduce and or time to reporduce.
13:34:01 hansmoleman comments inline
13:34:09 hansmoleman efried: what's the process now for placement bug fixes?
13:34:15 hansmoleman fix in nova and cherry pick to placement or vice versa?
13:35:39 sean-k-mooney oh right placement is moving...
13:39:29 mordred leakypipes, hansmoleman: +1 left - I agree with sean-k-mooney's followup comment
13:40:56 PapaOurs hansmoleman: AFAIUC, we need two changes
13:41:11 PapaOurs hansmoleman: and just waiting for the placement one to be merged before merging the nova one
13:41:16 PapaOurs but not Depends-On
13:42:00 finucannot hansmoleman: What would it cost me to get you to look at https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens+topic:bug/1746393 again?
13:42:30 finucannot hansmoleman: It's not something I'm going to be able to test with the Intel NFV CI but I did manually verify it
13:45:23 PapaOurs does someone remember the link for querying all the OpenStack project repos ?
13:46:17 hansmoleman codesearch.openstack.org
13:46:57 PapaOurs hansmoleman: <3
13:47:24 hansmoleman finucannot: how far back to plan on trying to get those backports? has that code just always been broken?
13:47:33 hansmoleman that stack seems extremely risky to me
13:47:40 hansmoleman especially when we have 0 CI
13:49:51 hansmoleman s/to plan/do you plan/
13:50:00 finucannot hansmoleman: Ideally back to when support for emulator threads was first added (Ocata) but Ocata is em now and I haven't even looked at the practicality of Pike. Queens would be good enough
13:50:33 finucannot Plus, Pike is just security/data loss bugs now anyway, right?
13:50:50 hansmoleman no
13:50:57 hansmoleman EM means we no longer have phases like that
13:51:29 hansmoleman https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
13:51:37 finucannot The more you know
13:52:02 sean-k-mooney leakypipes: ya i proably should have submitted it against placement.
13:52:02 finucannot But yeah, given how specific this is, whatever risk there is is going limited to select use cases
13:52:30 sean-k-mooney leakypipes: ill abandon after the ci results are in i mainly pushed to make sure this did not make anything else explode
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 leakypipes :P
13:57:44 sean-k-mooney also apparently i joinded redhat 90days ago as of monday.
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 PapaOurs fortunately, I'm hidden behind my nick
14:00:49 sean-k-mooney :)
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 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:22 hansmoleman but doesn't mean we need to backport that to queens
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

Earlier   Later