Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-30
17:15:28 mriedem gibi: sorry, forgot about the notification meeting
17:15:54 bauzas mriedem: jianghuaw: see the first rev for documenting the VGPU feature https://review.openstack.org/#/c/539266/
17:18:09 Spaz-Work Thanks for the ideas again bauzas, I think I hit the points you were concerned about
17:18:52 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Integrate Mypy Type Checking https://review.openstack.org/538217
17:30:11 gibi mriedem: no worries, as you saw there was nothing to talk about
17:34:32 mriedem bauzas: thanks, that's a nice start; comments inline
17:34:41 bauzas mriedem: I'm just passing a new rev now
17:34:45 bauzas will see your comments
17:34:54 mriedem passing, like a stone
17:35:36 bauzas mriedem: good points, will hold my rev and amend it with your comments
17:35:47 bauzas but that's somehow later tonight
17:35:50 bauzas bbrb
17:37:32 mriedem nova functional job timeout bump is getting promoted, #2 in the gate now
17:43:25 dansmith bauzas: still looking for you to comment on this: https://review.openstack.org/#/c/532924/
18:25:20 mriedem efried: cdent: are you aware of anyone writing any docs about how required traits will be used with flavors? was thinking about writing a functional test for alex_xu's traits / extra specs / scheduler series, and realized we probably don't have anything documented outside of the spec (which might have changed by now); thinking something here https://docs.openstack.org/nova/latest/user/flavors.html is the best place
18:26:09 cdent mriedem: I am not aware of anything, but I'd guess I'm about a week out of date on what's extant.
18:27:06 mriedem alright i'll see if i can work through a functional test and then document the user pov
18:33:27 melwitt mriedem: ack, will take a look at the CachingScheduler
18:44:08 efried mriedem: I assume you mean docs other than the spec
18:45:45 mriedem efried: yes. i expect specs as the last resort for usage docs
18:45:53 efried ++
18:59:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix nits in support traits changes https://review.openstack.org/537351
19:11:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Mention required traits in the flavors user docs https://review.openstack.org/539300
19:16:01 mgagne mriedem: "i expect specs as the last resort for usage docs" so should I update them ? I'm now on the fence on that one because I think that once implementation is done, you "should" be able to delete the spec. if doc is missing, I think it's a tech debt.
19:16:55 mriedem mgagne: specs shouldn't be deleted no,
19:17:16 mriedem for specs that require user-facing docs changes, there is a doc impact section, and it's up to reviewers to make sure the feature is documented
19:17:27 mgagne mriedem: what I meant is: once implementation is done, why should you rely on the spec? they can get out of sync easily
19:17:39 mriedem if some major part of a design point in a spec changed during implementation, or something was added, then we amend specs
19:17:57 mriedem lots of reasons - the problem statement, the original design ideas, etc
19:17:59 mriedem it's an archive
19:18:11 mgagne mriedem: that's not my experience so far as a spec reader
19:18:41 mriedem first, i'm not saying you should have to rely on a spec as a usage doc, it's not meant to be that
19:18:42 mgagne mriedem: ok, maybe not literally deleted but a end user shouldn't rely on that kind of documents
19:18:47 openstackgerrit Merged openstack/nova master: Bumping functional test job timeouts https://review.openstack.org/537933
19:18:58 mriedem if we're missing usage docs, that's a bug
19:18:59 mgagne mriedem: ok, we agree on that point
19:23:45 mgagne mriedem: tyvm for your work btw =)
19:27:21 openstackgerrit Merged openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961
19:27:31 openstackgerrit Merged openstack/nova master: Collapse duplicate error handling in rebuild_instance https://review.openstack.org/539001
19:32:19 openstackgerrit Merged openstack/nova stable/pike: Fix false positive server group functional tests https://review.openstack.org/536981
19:33:44 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
19:33:44 openstackgerrit Eric Fried proposed openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246
19:33:45 openstackgerrit Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517
19:33:56 efried jaypipes: Fixed those tests; should all be ready to go now ^
19:34:10 efried whoah, stuff is merging, neat.
19:36:21 mgagne mriedem: thanks for nova-caching-scheduler job, we do heavily rely on that driver. glad to see it won't get broken by accident before its removal.
19:36:45 mriedem mgagne: huawei public cloud is using it as well
19:36:53 mriedem so yeah i have to care about that one :)
19:36:59 mgagne mriedem: wasn't it them that made a presentation at the summit about it?
19:37:21 mriedem i don't remember one, but which summit?
19:37:29 mriedem it was added by rax
19:37:44 mgagne austin
19:37:59 mgagne was Intel
19:38:00 mgagne https://www.openstack.org/videos/austin-2016/dive-into-nova-scheduler-performance-where-is-the-bottleneck
19:38:06 mriedem yeah i remember that one
19:38:15 mriedem that was about a proposal for a different scheduler
19:38:57 mgagne difference of performance is like day and night (filter vs caching)
19:38:58 mriedem placement was pretty new still around that time so a lot of the outcome of that session (there was also a related design summit session) was "placement should handle a lot of these same issues"
19:39:40 mriedem i'm mostly interested, right now, in filter scheduler + placement vs caching
19:39:48 mriedem to see if that gap is much smaller
19:40:29 mgagne yes... because if placement is not as fast or close to be as fast, I would be like: "what's the point?" =)
19:41:46 prometheanfire mriedem: it's getting to the point where we'll need an FFE for https://review.openstack.org/538070 (if horizon doesn't merge that dependant patch)
19:42:47 efried jaypipes, mriedem: The final parts of update_provider_tree going to Rocky presents an opportunity to write that design up as a separate blueprint/spec. It was never outlined in any of the placement/NRP specs (right Jay?) and it really ought to be. If you agree, I can get started on that.
19:43:33 efried (If you don't agree, I'm going to write it anyway, for my own use, and you don't get to see it.)
19:44:30 mriedem prometheanfire: i'm not sure how much i want to pursue that this late given the impact it also has to some CLIs in OSC: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126741.html
19:45:40 prometheanfire mriedem: that's kinda what I thought
19:47:38 mriedem we'll just pick it up in rocky
19:47:47 mriedem nothing requires novaclient>=10.0.0 in queens
19:48:50 prometheanfire k
19:56:40 prometheanfire mriedem: k, gonna -2-W that for freeze then
19:58:00 mriedem prometheanfire: ok i left a comment in there that i'm cool with it
20:01:30 openstackgerrit Merged openstack/nova stable/pike: Set server status to ERROR if rebuild failed https://review.openstack.org/536897
20:06:25 melwitt more people are asking about https://review.openstack.org/340614 again, I've rewritten the commit message and added code comments to make it easier to review
20:08:16 mriedem i saw you dropped the revert history of shame
20:08:34 mriedem also, "people are talking" is a classic fox news tactic
20:08:41 mriedem name your sources mel
20:09:08 prometheanfire top
20:09:09 prometheanfire men
20:09:19 melwitt yeah, I had thought the history was important but I got the feeling no one could understand the point of the patch because of it
20:09:38 melwitt even I was getting confused between merge conflicts
20:09:39 prometheanfire https://www.reactiongifs.us/wp-content/uploads/2013/10/top_men_indiana_jones.gif
20:10:44 melwitt ayoung is asking about it today in #openstack-cinder
20:26:07 mriedem https://review.openstack.org/#/c/537933/ is finally merged, patches should flow much better through the gate now
20:27:45 prometheanfire mriedem: please have a piece of wood glued to your head :P
20:28:00 cfriesen melwitt: in the case of https://review.openstack.org/340614 why doesn't nova-compute do a more complete job of cleaning up at the time it sets the instance.host to None?
20:28:24 mriedem prometheanfire: ?
20:28:29 prometheanfire patches should flow much better through the gate now
20:28:53 mriedem cfriesen: like this? https://review.openstack.org/#/c/528385/
20:29:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional tests for traits-based scheduling https://review.openstack.org/539310
20:29:35 mriedem alex_xu: efried: ^
20:29:41 mriedem turned out it was pretty simple to write those
20:30:30 cfriesen mriedem: yep, and something similar for ports I guess.
20:34:56 openstackgerrit Matthew Edmonds proposed openstack/nova master: remove unnecessary conf imports https://review.openstack.org/539314
20:35:27 melwitt cfriesen: good question. looks like it tries to do something to cleanup volumes but it only does a volume delete if 'delete_on_termination' and doesn't do anything like detach volumes
20:35:51 melwitt so it seems like a better fix would be to properly handle cleanup in compute
20:37:21 mriedem melwitt: that's what ameeda's patch is trying to do
20:38:05 mriedem we do call _cleanup_allocated_networks when a build fails on the compute
20:38:10 mriedem which should cleanup ports
20:38:48 melwitt right
20:39:12 mriedem there could possibly be a bug there if we're using a stale network info cache

Earlier   Later