Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-07
19:08:12 openstackgerrit Dan Smith proposed openstack/python-novaclient master: WIP: Add aggregate-cache-images command and client routines https://review.opendev.org/687141
19:09:10 sean-k-mooney by the way you are not storing the cached state of the image anywhere correct? that is just known on the compute nodes
19:09:22 dansmith I'm really tempted to add a "check only" flag so you can single-shot the api and just say "check and see which of these aren't done to give at least the tiniest bit of reporting, but I think I need to resist the urge
19:09:29 dansmith correct
19:09:32 dansmith per the spec :)
19:10:14 sean-k-mooney yep im rebasing my schduler prefilter code to master and just wanted to confirm in my head that it should not conflict
19:10:19 dansmith many of the previous attempts stalled out at the persistence layer so I definitely want to punt on that
19:11:17 sean-k-mooney ya the tangent my brain was one was could you use a weighr to prefer the hosts wher eit was cached by reporting the cached images in the hostSate object
19:11:55 sean-k-mooney anyway not important now
19:12:42 dansmith sean-k-mooney: a weigher for exactly that is one of the ill-fated "previous attempt" items at the bottom of the spec
19:13:19 sean-k-mooney ah i see well there is nothing preventing it being added at a future point in your design
19:13:20 dansmith a sunken treasure for you
19:15:26 dansmith I want to roll this out and hear the requests and justifications for more complicated stuff
19:15:31 sean-k-mooney ah https://blueprints.launchpad.net/nova/+spec/node-cached-image-weigher
19:16:07 sean-k-mooney ya makes sense
19:30:26 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: report storage bus traits https://review.opendev.org/666914
19:30:27 openstackgerrit sean mooney proposed openstack/nova master: Add transform_image_metadata request filter https://review.opendev.org/665775
19:30:27 openstackgerrit sean mooney proposed openstack/nova master: libvirt: use domain capabilities to get supported device models https://review.opendev.org/666915
19:31:24 sean-k-mooney efried: do you mind removing your -2 from https://review.opendev.org/#/c/666914/ now that master is open for ussuri
19:32:08 efried sean-k-mooney: will do, but I'm going to put the bp "Direction" back to pending
19:32:30 efried done
19:32:48 sean-k-mooney efried: ok.
19:33:26 sean-k-mooney so does that mean it can still merger or does it have to wait till m2?
19:35:32 openstackgerrit Eric Fried proposed openstack/nova-specs master: Add 'Feature Liaison' spec process https://review.opendev.org/685857
19:36:26 efried sean-k-mooney: You can still merge code. But if when we have this planning discussion (format/timing/etc still tbd) it is decided we're going to cut it, we'll stop merging code for it.
19:36:43 sean-k-mooney ah ok
19:40:10 efried basically you still have to treat it as if it could end up partially merged, just like we normally do. IOW if it's a tightly-coupled series, we'll put -2 on the bottom until it's ready so it's all or nothing; otherwise we can merge it in stages.
19:40:35 efried btw, updated the core liaison (now feature liaison) patch, in case you were in mid-rebase ----^
19:41:56 sean-k-mooney efried: i upload my spec this morning ill rebase it again and update the section then im going to call it a day
19:42:34 sean-k-mooney oh maybe i did not push that
19:43:36 sean-k-mooney ya i still have it locally
19:50:45 sean-k-mooney i decied to try out http://spacemacs.org/ at the weekend. i have been using it all day and so far i like it
19:51:13 sean-k-mooney i disabled the vim keybindings but it works pretty well for me so far
19:51:42 sean-k-mooney not sure it will replace pycharm but it might replace my use of nano
19:52:14 openstackgerrit sean mooney proposed openstack/nova-specs master: Add spec for vm scoped sriov numa affinity https://review.opendev.org/683174
19:52:32 sean-k-mooney anyway o/
20:17:30 efried mriedem: how do we deal with bugs with a proposed fix that's now abandoned? Move back to the latest unassigned state and remove the owner?
20:19:01 dansmith yes
20:20:03 openstackgerrit Dan Smith proposed openstack/nova master: Add cache_image() support to the compute rpc, api, and manager https://review.opendev.org/687138
20:20:04 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Add image caching API for aggregates https://review.opendev.org/687140
20:20:04 openstackgerrit Dan Smith proposed openstack/nova master: Add cache_images() to conductor https://review.opendev.org/687139
20:29:46 mriedem efried: yeah, there are cases where if i'm familiar with the thing i can just close it as invalid (or fixed by something else)
20:29:53 mriedem if it has to go back through triage or whatever though yeah
20:30:10 efried k, thx
20:31:14 mriedem dansmith: gonna throw your stuff in https://etherpad.openstack.org/p/nova-runways-ussuri ?
20:39:19 openstackgerrit Artom Lifshitz proposed openstack/nova master: Helper to start computes with different HostInfos https://review.opendev.org/686832
20:39:20 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP] Functional tests for NUMA live migration https://review.opendev.org/672595
20:39:34 artom mriedem, dansmith ^^ if you get a chance to start taking a look
20:39:47 artom I left the main func tests as WIP because I want to add a test for the thing that ya.wang found
20:41:11 openstackgerrit Artom Lifshitz proposed openstack/nova master: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/682622
20:41:11 openstack bug 1843639 in OpenStack Compute (nova) "libvirt: post_live_migration failures to disconnect volumes result in the rollback of live migrations" [Medium,In progress] https://launchpad.net/bugs/1843639 - Assigned to Lee Yarwood (lyarwood)
20:41:11 openstackgerrit Artom Lifshitz proposed openstack/nova master: Add regression test for bug #1843639 https://review.opendev.org/682621
20:41:44 mriedem artom: just a thought, but you don't need to load up every test ever into the same patch for the numa lm functional stuff
20:42:01 mriedem like, happy path + framework stuff and then build on top in separate changes the weird edge cases and failure/rollback scenarios
20:42:09 mriedem that would make it a lot easier to review as well
20:42:14 openstackgerrit Merged openstack/nova master: Error out interrupted builds https://review.opendev.org/666857
20:42:42 artom mriedem, true
20:42:50 artom It'd make the reviewing more breakdown-able, in any case
20:42:52 artom Not sure about easier
20:43:14 mriedem broken down usually means easier
20:43:47 mriedem it would at least be easier for me to get the motivation to get started if it wasn't 1K in a single change...
20:43:55 artom I was thinking in the sense of "reviewing one test method/class per day" can be done in either case
20:43:56 mriedem a single WIP change at that
20:44:08 mriedem i guess it's not 1K
20:44:22 artom If you'd prefer it split into smaller chunks I can do that
20:44:50 artom But you'll just get 5 200LOC patches with a test class each instead of 1 KLOC patch with 5 test classes ;)
20:45:15 mriedem that's essentially what i did with the functional tests for cross-cell resize
20:45:29 mriedem starting here and then going up https://review.opendev.org/#/c/636253/
20:46:20 mriedem i guess my point is seeing WIP + lots of code makes me really not want to start reviewing it :)
20:46:32 mriedem i will find any reason to procrastinate with something else
20:46:50 artom Fair enough - it's not like I didn't procrastinate :)
20:47:06 artom But... even if I -1 random changes of your for tenuous reasons? ;)
20:47:12 artom *of yours
20:47:49 mriedem you mean that will make me want to review your stuff *more*?
20:47:55 artom It doesn't?!
20:48:05 mriedem it might add to the guilt complex
20:48:10 artom I've been doing it wrong all this time! (by which I mean a week)
20:48:47 mriedem efried: i added cross-cell-resize to the ussuri runways queue, are we able to queue stuff up now?
20:50:09 efried mriedem: might as well.
20:50:39 mriedem efried: ok you could probably drop the -2 on https://review.opendev.org/#/c/674243/ as well
20:51:36 efried done
20:52:08 dansmith mriedem: how does runways work with the new process? I guess I had kinda imagined that we weren't going to do that
20:52:36 mriedem goto efried
20:52:52 efried (how) did it work before?
20:53:03 mriedem i wouldn't think the new spec approval process would change anything about runways
20:53:08 mriedem when feature code is ready queue it up
20:53:29 mriedem i guess i haven't dug into the new definition/direction stuff yet...
20:53:48 mriedem if a blueprint is approved and the code is ready for review i don't know why it wouldn't be in runways though
20:54:10 dansmith yeah, tbh it's less clear to me today than it was last week when we discussed,
20:54:12 efried Right, the only thing the additional "we're gonna constrain stuff" process would change is, if whenever we do the constraining activity we decide to drop something that's already got unmerged code proposed, we would -2 whatever's on bottom at that time.
20:54:25 dansmith plus the whole feature chaperone thing has me more confused
20:54:26 efried so play fast an loose until whenever we do that.
20:54:39 efried dansmith: did you read the faq? I updated it a couple hours ago.
20:54:58 dansmith no, but I read the comments that led to the change
20:55:18 mriedem official hand holder is just to help someone navigate the review process as far as i know
20:55:31 efried dev & review. Yes.
20:55:46 dansmith yeah, I get that
20:55:54 dansmith anyway, don't want to get back into it right now
21:06:35 dansmith mriedem: there's a lot more boilerplate required in API patches since the last time I wrote one.. any chance we have a checklist or something I can follow?
21:06:45 dansmith api samples, api refs, schema crap, etc, etc

Earlier   Later