Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-21
21:02:23 jaypipes mriedem: that is 2 lines Matt. Un. Friggin. Acceptable.
21:02:59 mriedem artom: there are more cores here than me
21:03:19 mriedem artom: at this point i'm pushing to get the bw provider stuff in before FF
21:03:25 artom mriedem, I know. You reviewed the spec is why. But I get that you're oversubscribed as is.
21:03:44 sean-k-mooney jaypipes: he did say about 1 line :P
21:04:07 artom Which is why I mentioned efried :) Intel are apparently keep on it.
21:04:51 mriedem artom: what's the test story on that series? is https://review.openstack.org/#/c/634606/24/nova/tests/functional/compute/test_live_migration.py the most functional we have?
21:05:02 artom mriedem, in-tree, yeah
21:05:20 artom I wrote https://review.rdoproject.org/r/#/c/18832/ that I've been using in my devstack
21:05:24 efried artom: I have been requested both internally and externally to have a look at that. Unfortunately, it's behind a number of other things, as well as requiring quite a bit of homework on my part just to grok the background. I think alex_xu is involved though, right?
21:05:51 artom efried, not really, you're our only hope (Obi Wan)
21:05:51 jaypipes sean-k-mooney: :P
21:06:51 artom So, it's easy for me to get stephenfin to look at it, being the same company and all
21:06:57 sean-k-mooney artom: the code freeze is still a few weeks away. we shoudl be able to get to it once bw feature is in
21:07:02 artom It's the other non-RH core that's the problem
21:07:16 mriedem i also have like a 50 change series of my own
21:07:34 artom ... and who groks NUMA? jaypipes I guess? But you're as oversubscribed as mriedem.
21:08:00 mriedem i definitely know how the live migration flow in compute manager and claims shit works, so i should look at it
21:08:05 mriedem but god
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

Earlier   Later