Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
10:57:21 aspiers not sure if there are other implications
10:57:41 efried to refine the question: Is this going to affect a) gate, b) vpmem/cpu-resources series?
10:58:01 aspiers I don't think it affects nova at all
10:58:09 aspiers We probably would have noticed by now if it did
10:58:26 efried then I humbly request the issue be raised *after* this week
10:58:40 aspiers I think it's just for registering metadata as "officially blessed" rather than some arbitrary key/value pair
10:58:42 gibi bauzas, efried: lost a +W in a rebase https://review.opendev.org/#/c/676972 could you please add it back?
10:58:53 aspiers efried: haha sure, it can't be urgent :)
10:59:12 aspiers efried: but probably trivial to fix too, and anyway it's a matter of submitting reviews to glance not nova
10:59:31 efried gibi: done, but you should feel free to re+W in these circumstances
10:59:48 efried aspiers: cool
10:59:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497
11:00:26 gibi efried: ack, will do
11:03:27 sean-k-mooney efried: i see bauzas ack'd https://review.opendev.org/#/c/671800/34 but ill take a look now too
11:04:02 efried sean-k-mooney: if you like. Though actually I would rather you re-looked at that one vpmem patch...
11:04:18 efried sean-k-mooney: this un https://review.opendev.org/#/c/678455/36
11:04:21 sean-k-mooney efried: sure
11:04:43 efried thank you
11:04:44 sean-k-mooney looking at teh cpu seriese have they all been approved
11:04:49 efried mostly
11:04:59 efried we're still working on a couple at the top
11:05:15 efried remember that thing about trying a second GET /a_c if the first one returned no results?
11:05:31 sean-k-mooney ok so we are waiting on the gate for most of them and fixing the last few patches
11:05:41 sean-k-mooney efried: ya
11:05:57 sean-k-mooney efried: is it causing issues
11:05:58 efried I'll save you reading the backscroll, but we're doing something different now: we're going to do both GET /a_c calls up front (with a workaround conf opt)
11:06:13 efried Stephen is working on that now
11:06:21 sean-k-mooney ok
11:06:28 sean-k-mooney what is the advantage of that
11:06:49 sean-k-mooney are we doing them in parallel or something
11:06:57 efried with the cascaded approach, if we did the first one, got results, then sent them down to the filter and the filter rejected all of them, we'd be hosed.
11:07:15 efried So one option was to make that retry "wider"
11:07:22 efried which would be tough to code
11:07:40 artom efried, has that configparser thing been fixed? I see you rechecked the NUMA LM patches
11:07:44 sean-k-mooney ok i see
11:07:47 efried artom: yes
11:07:52 artom Sweet
11:07:54 efried artom: carefully curating the gate atm
11:08:04 efried sean-k-mooney: no, we have to do them sequentially, because we always want to try the pcpu ones first for a given host.
11:08:04 artom Yep, thanks for that
11:08:28 efried but we do one right after the other
11:08:35 efried and collect all the candidates
11:08:41 efried then send them all down to the filter.
11:08:58 sean-k-mooney right
11:09:24 sean-k-mooney i assume we only add host form the second query if its not in the first?
11:09:36 sean-k-mooney or do we just let the filter handel that
11:09:41 efried I don't think we're being that careful about it
11:09:51 sean-k-mooney actully it does not matter
11:09:54 efried right
11:10:19 sean-k-mooney the filter work on host not allocation candiates
11:11:01 sean-k-mooney so it will pass the host if it fit and fail it if it does not
11:11:23 sean-k-mooney and the host will only support one of the two with pinning
11:12:15 sean-k-mooney a host can have VCPU and PCPUs but if it returns pcpu allocation then that is what we will need to use
11:14:42 sean-k-mooney efried: by the way this https://review.opendev.org/#/c/679656/ is the numa live migration job. it not a pirortiy today but i would like to merge that before RC1 to get it running nightly once artoms code is fully merged.
11:15:04 sean-k-mooney it add the nova-nfv-multi-numa-multinode job
11:15:16 efried sean-k-mooney: ack, please ask about it next week
11:15:33 sean-k-mooney yep will do
11:16:45 efried sean-k-mooney: https://review.opendev.org/#/c/681358/ os-vif release ack pls?
11:17:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize https://review.opendev.org/678827
11:17:09 sean-k-mooney mels patch ya ill ack that now
11:20:04 openstackgerrit Stephen Finucane proposed openstack/nova master: fixup! Add support for translating CPU policy extra specs, image meta https://review.opendev.org/681719
11:20:29 stephenfin efried, sean-k-mooney, alex_xu, bauzas: Before I squash that back and fix the tests, want to give that the once over ^ ?
11:20:55 alex_xu yup, checking now
11:21:09 efried ...
11:25:02 alex_xu ah, that is smart
11:26:00 alex_xu stephenfin: works for me
11:26:43 sean-k-mooney checking
11:27:01 efried stephenfin: looks good, couple of comments in there.
11:29:58 luyao sean-k-mooney: Hi, if you get time, could you help look vpmem xml again? thanks ( we discussed before about the numa requiring and alignment, and got a consensus about them)
11:30:29 luyao https://review.opendev.org/#/c/678455/
11:31:51 sean-k-mooney efried: also commented. we should not use update as i noted inline
11:32:22 stephenfin efried: I shouldn't have pushed those mox patches through last night either. Sorry :(
11:32:42 efried no biggie stephenfin
11:33:00 efried they're all going to get kicked out here in a minute
11:33:05 sean-k-mooney luyao: yep i have it open efried pinged me earlier
11:33:29 sean-k-mooney im just going to grab coffe then ill review the vpmem seriese in full starting with the xml patch
11:33:31 stephenfin cool. I switched to -2 on the bottom one to make it clear
11:33:36 luyao sean-k-mooney: hah, thanks
11:35:00 stephenfin On the other hand, once that lands mox is basically gone. It's only been four years \o/
11:35:19 efried sean-k-mooney, stephenfin: It's not important enough to spend a bunch of time on, but am I crazy about .update()?
11:35:38 stephenfin in relation to...?
11:35:42 efried a psum is a psum
11:36:16 efried the way you're doing it I guess you're not replacing one that's already there, whereas .update would (redundantly) replace
11:36:33 stephenfin I need a link
11:36:45 efried I guess python probably isn't smart enough to skip
11:36:48 sean-k-mooney oh maybe i miss understood
11:36:52 efried so yeah, I guess the way you're doing it is going to be more efficient
11:36:56 efried but the result will be the same
11:37:01 sean-k-mooney i though stephen was filtering the allocation candiate but he is not
11:37:10 efried just question of whether you want fewer LOC I guess
11:37:23 efried stephenfin: https://review.opendev.org/#/c/681719/1/nova/scheduler/manager.py@197
11:37:30 sean-k-mooney update is fine for the summaries
11:37:51 sean-k-mooney i would prefer if we filtered this however
11:37:53 sean-k-mooney Draft
11:38:17 sean-k-mooney alloc_reqs.extend(alloc_reqs_fallback)
11:38:45 efried sean-k-mooney: filter it how?
11:38:59 stephenfin efried: tomato tomato. As you say, it doesn't matter
11:39:07 stephenfin I'm happy to go with '.update()'
11:39:10 sean-k-mooney is that the set of alloction candiates
11:39:13 efried we explicitly can't skip the ones we already have PCPUs for

Earlier   Later