Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-30
16:37:18 Spaz-Work mock patching hurting my brain
16:37:27 openstackgerrit Ed Leafe proposed openstack/nova master: Fix invalid UUIDs in remaining tests https://review.openstack.org/539254
16:37:32 edleafe stephenfin: ^^
16:38:35 mdbooth stephenfin: https://review.openstack.org/#/c/539247/1/nova/tests/unit/virt/libvirt/test_vif.py does nova.network.model use o.v.o. ?
16:39:08 stephenfin mdbooth: It uses os-vif objects, which are o.v.o based
16:39:42 mdbooth stephenfin: I believe you, but... where?
16:39:44 stephenfin Wait, I have that confused
16:39:55 dansmith yeah, no
16:40:00 dansmith that stuff is not o.vo based
16:40:03 mdbooth Given that both you and edleafe have made the same changes, I assume they're required
16:40:04 dansmith nor versioned
16:40:12 mdbooth I just can't see where the dep comes in
16:41:09 stephenfin I never really thought to question the warnings, but there is something going on there with os-vif. Lemme root it out
16:41:59 edleafe mdbooth: did you see the warnings? They're listed in the bug
16:42:23 stephenfin mdbooth, dansmith: It's nova/network/os_vif_util.py
16:42:55 stephenfin We have code to convert nova's VIF/network/<other networking thingys> to os-vif equivalents
16:42:59 stephenfin which _are_ versioned
16:51:38 mdbooth stephenfin: How would I reproduce these warnings? I just ran the tests in nova.tests.unit.virt.libvirt.test_vif, and I didn't get any uuid warnings
16:51:57 mdbooth Just warnings about deprecation of api extensions
16:52:42 dansmith stephenfin: aye
16:53:10 stephenfin mdbooth: I think you've to trigger something to do with PYTHONWARNINGS. I was seeing them when I ran the testsuite with pytest
16:53:26 stephenfin mdbooth: They should be visible in any recent gate logs
16:54:45 stephenfin mdbooth: This is the warning that's being raised https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L346
16:55:01 dansmith mriedem: do we have a bug for the need-a-limit thing? if not, I assume I should open one at this point because FF
16:57:00 openstackgerrit Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865
16:57:28 mriedem dansmith: nope no bug but was considering it a bug fix anyway
16:57:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a nova-caching-scheduler job to the experimental queue https://review.openstack.org/539260
16:57:34 mriedem dansmith: feel free to open one though
16:57:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865
17:00:09 openstackgerrit Dan Smith proposed openstack/nova master: Pass limit to /allocation_requests https://review.openstack.org/531517
17:00:14 dansmith mriedem: ^
17:13:39 openstackgerrit Brooks Kaminski proposed openstack/nova master: XenAPI/Stops the migration of volume backed VHDS https://review.openstack.org/533168
17:15:13 openstackgerrit Sylvain Bauza proposed openstack/nova master: Provide support matrix and doc for VGPU https://review.openstack.org/539266
17:15:27 openstackgerrit Ed Leafe proposed openstack/nova master: Fix invalid UUIDs in remaining tests https://review.openstack.org/539254
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: Use update_provider_tree from resource tracker https://review.openstack.org/520246
19:33:44 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
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

Earlier   Later