| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-21 | |||
| 21:08:25 | artom | To be fair, there's very little actual NUMA, bizarely | |
| 21:08:32 | artom | In the sense that it uses a lot of existing code | |
| 21:08:40 | artom | So if you assume those bits works, it's just about the glue | |
| 21:09:08 | sean-k-mooney | artom: that because your useing the existing code to calulate the topology on the destination then just sending it back to the source and updating the xml | |
| 21:09:20 | artom | Yep, what sean-k-mooney said | |
| 21:09:22 | mriedem | if it's ready for review just put it in runways | |
| 21:09:30 | sean-k-mooney | so most of that code is common | |
| 21:09:38 | mriedem | you can have other RH cores review it and do the honorable and not +W | |
| 21:09:43 | mriedem | like dansmith and melwitt | |
| 21:10:19 | artom | mriedem, yep :) | |
| 21:10:32 | artom | Was trying to gauge interest/chances. So not a slam dunk, to put it mildly ;) | |
| 21:10:57 | artom | ;) | |
| 21:11:07 | mriedem | sorry | |
| 21:11:18 | mriedem | i'll get to what i can when i can | |
| 21:11:21 | melwitt | yes, I should help review that. currently toiling on my own patch series for counting quota usage from placement | |
| 21:11:28 | artom | mriedem, heh, no need to apologise :) | |
| 21:12:41 | sean-k-mooney | artom: has cfriesen reviewed the code by the way. he will be interested in it. im setting up at test env currently and will fully re review it proably early next week | |
| 21:13:31 | artom | sean-k-mooney, I poked him a while ago, when it was still all WIP | |
| 21:13:43 | cfriesen | I'm totally swamped with a downstream cust issue | |
| 21:13:45 | artom | Let's consider him poked a second time | |
| 21:13:47 | mriedem | efried: ok you and my anxiety over ^ has made me approve https://review.openstack.org/#/c/619528/ | |
| 21:14:11 | mriedem | i trust gibi to do me right | |
| 21:14:49 | sean-k-mooney | cfriesen: no worries | |
| 21:15:48 | efried | mriedem: ack. I think it's the right thing. If you propose the fup and have gibi +2 it, that would be swimming. | |
| 21:16:06 | artom | (We're doing a retro at PTG, right? We could talk about better planning - it feels like we all have our pet series, plus the cores have an "obligation" to review other stuff) | |
| 21:16:38 | mriedem | artom: remember how many times throughout the release i asked you and stephenfin how that series was coming since no patches were posted, even WIP? | |
| 21:16:50 | efried | artom: add retrospective section with that line to https://etherpad.openstack.org/p/nova-ptg-train | |
| 21:17:17 | artom | mriedem, oh, I'm fully acknowledging my responsibility in this being massively late | |
| 21:17:45 | melwitt | yes, we do a retro each ptg and yep, just add info there. we usually have a separate etherpad we link to from the ptg pad, since the ptg pad ends up being ginormous | |
| 21:17:46 | mriedem | ok :) | |
| 21:17:55 | artom | I understand that I can't rock up and be like "y'all got 2 weeks to merge my shit" | |
| 21:19:10 | artom | But... it doesn't mean I'll stay silent and not push for it :) | |
| 21:19:32 | artom | That being said, if it doesn't merge I'll only have myself to blame | |
| 21:20:22 | sean-k-mooney | artom: by the way ill need to test this on my hadware setup. ubuntu crashes the l2 guest with nested virt. on centos booting the l2 guest crashes the l1 guest kernel... so i think i need to do a bios/micorcode upgrade before i can do nested ver on my new server :( | |
| 21:20:40 | artom | sean-k-mooney, devstack on fedora 29 works great for me | |
| 21:21:04 | sean-k-mooney | i might test it on my laptop actully nested virt works fine there | |
| 21:21:32 | melwitt | artom: yeah, I think we (or at least I) am just wondering what you mean by "better planning" in this case. not that you're trying to get review lately | |
| 21:21:53 | sean-k-mooney | that said i spent 1300 euro on the workstation to do nested virt ci so i need to fix it anyway | |
| 21:22:06 | melwitt | (and that's mostly rhetorical, we will discuss that on the retro) | |
| 21:22:18 | artom | melwitt, in the sense of committing to less, given our collectives bandwithes | |
| 21:22:23 | artom | (Band... wii?) | |
| 21:22:33 | melwitt | ah. yeah, the eternal issue | |
| 21:24:17 | sean-k-mooney | artom: if noting else there will be a number of low hanging fruit feautre that can land in early trian | |
| 21:24:26 | melwitt | I think if things were staggered more, it would mostly work. but life happens and many things end up coming in at the same time at the end of the cycle, at least that's what it seems to me | |
| 21:24:56 | artom | Heh, naturally, if there's only 1 deadline, everyone will procrastinate until that deadline | |
| 21:25:48 | melwitt | :) | |
| 21:26:54 | mriedem | we've had multiple feature freeze deadlines in the past mind you | |
| 21:26:58 | mriedem | priority and non-priority ff | |
| 21:27:07 | mriedem | and people don't like that either for similar reasons | |
| 21:27:23 | mriedem | can't really process your way out of these problems | |
| 21:27:50 | artom | A thing we do downstream is just punt waaaay early | |
| 21:28:00 | artom | So like, by upstream spec freeze if there's no code up it's punted | |
| 21:28:22 | sean-k-mooney | well that is what the the non priorot feature freeze used to do | |
| 21:28:36 | artom | The live migration stuff is sorta an exception because everyone wants it, so we both punted to Train *and* kept it around in Stein just in case | |
| 21:28:50 | sean-k-mooney | if it was not a priority feature and it was not done by m2 it got punted | |
| 21:29:53 | artom | Maybe not split into priority/non-priority? Just "no patches ready for review by spec freeze? Punt." | |
| 21:30:04 | artom | And then there's more collective bandwidth for the remaining stuff | |
| 21:30:14 | artom | I dunno, we can bikeshed more at the retro I guess | |
| 21:30:39 | melwitt | yeah. open to ideas there, we'll talk about it then in more detail | |
| 21:31:16 | sean-k-mooney | honestly any feature that misses FF i would hope we coudl just target at m1 and actully aim to get more stuff done at teh earliar milestones | |
| 21:31:53 | mriedem | ^ is why we have runways | |
| 21:32:30 | sean-k-mooney | that is true. | |
| 21:32:37 | artom | So, honest question, do they work? For instance, sean-k-mooney's SRIOV live migration stuff got a runway, and then no-one (and I'm just as guilty here) reviewed it | |
| 21:33:31 | mriedem | sure they do | |
| 21:33:42 | mriedem | plenty of stuff has been merged from runways b/c of runways | |
| 21:33:45 | mriedem | trusted certs for example | |
| 21:33:58 | sean-k-mooney | with the bandwith stuff in another runway and with the priority fo that im honestly not that surprised. i think they do help | |
| 21:34:05 | mriedem | there are some things that people just don't have as a priority to review, or comfort in reviewing | |
| 21:34:32 | sean-k-mooney | ya i think it more the latter with the numa stuff | |
| 21:34:44 | sean-k-mooney | few people feel comfortable to review it | |
| 21:34:56 | mriedem | ok i need to do this fup and move on | |
| 21:35:26 | melwitt | and I have to run to an appointment. bbl | |
| 22:04:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Follow up for I0c764e441993e32aafef0b18049a425c3c832a50 https://review.openstack.org/638517 | |
| 22:04:42 | mriedem | jaypipes: efried: ^ | |
| 22:05:27 | efried | way to go on that "about one line" thing. | |
| 22:06:05 | mriedem | i wasn't going to make all of the changes in his original patch | |
| 22:06:17 | mriedem | so i went with the full fup and todo's the provider trait cache thing for him :) | |
| 22:16:19 | sean-k-mooney | mriedem: by the way i started review your cross cell migration stuff but before i dig into that series to much is it complete. | |
| 22:17:50 | mriedem | there are still kinks i have to work out and more testing to be added | |
| 22:17:51 | sean-k-mooney | im planning on my sriov migration series and artoms numa migration series again next week. i could try and add your cell migration series to that list if i can make time | |
| 22:18:07 | sean-k-mooney | *planning on testing | |
| 22:18:19 | mriedem | i have no illusions that cross-cell resize is going to land in stein | |
| 22:18:48 | mriedem | but review would be useful nonetheless to get more than just my eyes on it, | |
| 22:18:57 | mriedem | Kevin_Zheng has been reviewing some of it along the way as well | |
| 22:19:14 | mriedem | functional tests start at the change that gets the server to VERIFY_RESIZE status | |
| 22:19:44 | mriedem | i have a known issue with volume attachment tracking as well | |
| 22:20:16 | mriedem | it's all from the bottom up though, so technically we can start merging things and none of it will be used until the very end of the series | |
| 22:20:44 | sean-k-mooney | ok well while i have at least some of the context of that code loaded i thikn it makes sense to spend my review time on it abit next sprint | |
| 22:20:44 | mriedem | if people need a review guide (like gibi did for the bw provider series) i can post something in the ML | |
| 22:23:37 | sean-k-mooney | mriedem: well i havent gotten to any of the involed code yet but sofar all your patches are fairly clear and too the point. you also tend to front load the context with a decent commit message so a review guide might be useful but so far the 2 or 3 patches i have looked at are pretty self evendely correct | |
| 22:25:26 | mriedem | honestly there is a shit load of documentation because i have to keep it straight myself | |
| 22:30:07 | sean-k-mooney | maybe my tastes are changing but while i like self documenting code as i have been looking at longer patchset lately i have found my self like self documetning code with comments and documentation more | |
| 22:31:27 | mriedem | i think you just said the same thing | |
| 22:31:32 | mriedem | "like i like A, i like A" | |
| 22:31:36 | mriedem | *while i like A, i like A | |
| 22:32:06 | mriedem | maybe i don't know what self-documenting code is | |
| 22:32:17 | mriedem | it's what research type people say when you ask what their code does :) | |
| 22:32:19 | mriedem | in my experience | |
| 22:32:56 | sean-k-mooney | for me it its code that is written in such a as the variable names and function make it clear what it should do without requiring a comment | |
| 22:34:03 | sean-k-mooney | but lately even when that is the case i have found that a comment explaining why it does X not how it does x which is obvios for the code is someting i have been thinking about more | |