| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 18:54:48 | mriedem | granted backporting an rpc change for rc2 would be.. | |
| 18:54:54 | dansmith | but no crazy rush so that's fine | |
| 18:55:08 | openstackgerrit | Merged openstack/nova master: Update reno for stable/queens https://review.openstack.org/542658 | |
| 18:59:12 | esberglu | edmondsw: What's the best way to test this? I can assert that the __init__ methods are being passed the right args | |
| 18:59:29 | edmondsw | esberglu autospec? | |
| 19:04:11 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add z/VM Driver in Rocky https://review.openstack.org/536186 | |
| 19:06:28 | openstackgerrit | Merged openstack/nova-specs master: Modify grammatical errors https://review.openstack.org/541765 | |
| 19:15:58 | mriedem | melwitt: need to re-propose https://review.openstack.org/#/c/500975/ for rocky | |
| 19:19:29 | openstackgerrit | Mark Goddard proposed openstack/nova master: Unplug all VIFs from ironic nodes during tear down https://review.openstack.org/537626 | |
| 19:25:47 | mriedem | jianghuaw: remember to bring this bp up during the nova meeting at some point (after the holiday at this point) https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement | |
| 19:26:32 | mgoddard | mriedem: I've just seen your ML email about backports. Would https://bugs.launchpad.net/nova/+bug/1748942 qualify? The fix is simple, and limited to the ironic virt driver | |
| 19:26:33 | openstack | Launchpad bug 1748942 in OpenStack Compute (nova) "Ironic virt driver should not JSON encode traits in instance_info" [Undecided,In progress] - Assigned to Mark Goddard (mgoddard) | |
| 19:26:57 | mgoddard | mriedem: fix is this: https://review.openstack.org/#/c/543574/1 | |
| 19:27:49 | mriedem | mgoddard: so traits-based scheduling with ironic+nova doesn't work without this fix? | |
| 19:28:27 | mriedem | or what is instance_info.traits used for? | |
| 19:28:36 | mriedem | i thought that was something to do with the capabilities filter in nova | |
| 19:28:45 | mriedem | which we're superseding with placement + traits | |
| 19:29:27 | mgoddard | mriedem: the scheduling works, but any flavor-requested traits won't be pushed to the ironic node's instance_info. These are not yet used by ironic, but will be used in future for some capabilities-like things | |
| 19:29:48 | mriedem | mgoddard: if they aren't used in ironic in queens, then it's not something worth holding up rc2 IMO | |
| 19:29:49 | mgoddard | or rather, they are pushed incorrectly | |
| 19:30:03 | mriedem | i assume you're asking about this for rc2 | |
| 19:30:11 | mriedem | rc2 changes at this point == stop ship | |
| 19:30:25 | mriedem | once we release queens 17.0.0 we can backport regular old bug fixes to stable/queens as usual | |
| 19:31:07 | mgoddard | mriedem: I suspect you're right - it isn't sufficiently important to block rc2 | |
| 19:31:29 | mriedem | does ironic have a tempest plugin? | |
| 19:31:45 | mriedem | ooo look it does https://github.com/openstack/ironic-tempest-plugin | |
| 19:31:49 | mgoddard | mriedem: it does | |
| 19:32:13 | mriedem | can we work on something in there that actually uses real live traits to make sure the plumbing is all correct between the two projects? | |
| 19:33:50 | mgoddard | mriedem: that sounds sensible | |
| 19:34:03 | mgoddard | mriedem: I'll look into it | |
| 19:34:11 | mriedem | thanks | |
| 19:34:26 | mriedem | this amount of coupling between projects means we really need some higher level integration testing | |
| 19:34:29 | mriedem | than unit tests | |
| 19:36:47 | mgoddard | there are tempest tests covering the ironic traits API, but you're right in needing to test the nova-ironic interface | |
| 19:46:02 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 19:52:33 | efried | mriedem: I wouldn't mind, but shouldn't edleafe or jaypipes repropose the NRP spec? | |
| 19:55:37 | mriedem | efried: ed did it in queens, | |
| 19:55:44 | mriedem | i think anyone familiar with the changes can do it | |
| 19:55:46 | mriedem | which i think you are | |
| 19:56:55 | efried | mriedem: Roger that. jaypipes edleafe Any objections? | |
| 19:57:09 | efried | ... or local WIP already? | |
| 19:58:20 | edleafe | efried: not from me | |
| 20:06:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886 | |
| 20:08:07 | mriedem | dansmith: we likely want 1 or 2 blueprints for rocky for cellsv1 and nova-network removal...figured you'd like to create those | |
| 20:08:26 | mriedem | the nova-net removal is going to be a pita b/c of our functional and unit tests that rely on stubs and crap | |
| 20:11:43 | jaypipes | efried: nope, go for it. | |
| 20:11:54 | efried | ack | |
| 20:12:36 | efried | jaypipes, edleafe: Though some of these assumptions (e.g. about NUMA) have... "evolved". | |
| 20:12:44 | efried | ...or are under discussion. | |
| 20:14:58 | edleafe | efried: yeah, that's why we need to re-propose: to reflect today's situation | |
| 20:15:25 | mriedem | did somebody say "the situation"? | |
| 20:15:32 | efried | edleafe: Considering how much of the work is done, and how we've refined/detailed what remains, it's pretty much gonna be a brand new spec. | |
| 20:15:45 | mriedem | http://pmcdeadline2.files.wordpress.com/2014/03/mike-the-situation__140331172717.jpg | |
| 20:16:00 | efried | Which means no fast approval. But hopefully closer fidelity to reality. | |
| 20:16:03 | edleafe | efried: isn't that always the case? :) | |
| 20:16:28 | edleafe | mriedem: ah, your laptop's background image | |
| 20:16:40 | mriedem | i use it as motivation | |
| 20:16:46 | mriedem | to be jerseylicious | |
| 20:17:28 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add regression test for BFV+IsolatedHostsFilter failure https://review.openstack.org/543602 | |
| 20:17:29 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Fix docs for IsolatedHostsFilter https://review.openstack.org/543604 | |
| 20:17:29 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Handle volume-backed instances in IsolatedHostsFilter https://review.openstack.org/543603 | |
| 20:18:43 | mriedem | efried: how much of the change to the spec is implementation details vs just high level design? | |
| 20:19:48 | efried | mriedem: Let me finish my initial reread and get back to you on that. But at a glance, the main thrust of the spec is implementing root_provider_uuid and parent_provider_uuid, which is done. What remains, and what we should probably give a little more detail about, is the GET /allocation_candidates changes. | |
| 20:20:59 | mriedem | then for the done stuff, say it's done in queens and update the not-yet-done-stuff parts | |
| 20:21:49 | efried | mriedem: That latter part isn't even mentioned in this spec. | |
| 20:22:21 | efried | But yeah. I'll do the needful. | |
| 20:22:33 | efried | There will be controversy over NUMA, though. | |
| 20:22:43 | mriedem | efried: well, if the NRP spec is all about stuff that's already done, then there probably isn't a need to re-propose it, | |
| 20:22:56 | mriedem | and we create a new bp/spec for the things that are pending and move all of those changes under that new bp? | |
| 20:23:11 | mriedem | but i deferred the NRP bp from queens b/c there were remaining things to use it | |
| 20:23:20 | efried | mriedem: Finished reading now, and yeah, that's kinda what I was thinking. | |
| 20:24:04 | efried | mriedem: I think that (deferring/remaining) was a reflection of "scope creep". | |
| 20:24:09 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html#work-items | |
| 20:24:16 | mriedem | the last 2 bullets in there aren't done are they? | |
| 20:24:22 | efried | mriedem: Nor will they be. | |
| 20:24:28 | efried | Cause that's no longer the plan. | |
| 20:24:33 | mriedem | oy | |
| 20:24:50 | mriedem | ok, so the nrp spec became the api stuff and foundational plumbing, | |
| 20:25:08 | mriedem | and support for modeling numa and sriov are separate new thing snow | |
| 20:25:10 | mriedem | yeah? | |
| 20:25:30 | efried | That's part of the story, yes. | |
| 20:25:51 | mriedem | if that's the case, then maybe we should amend the queens spec, and mark the bp as done for queens, even though we don't have numa/sriov modeling with it | |
| 20:26:22 | efried | If the update_provider_tree stuff had gotten finished in Q, it would have been tucked under the umbrella of the nrp blueprint (most of it was merged under that topic) even though it was never mentioned or even hinted at in the nrp spec. | |
| 20:26:41 | edleafe | jaypipes: cdent: efried: dansmith: mriedem: wrote up something quick on my ideas on affinity: https://blog.leafe.com/modeling-affinity/ | |
| 20:26:49 | edleafe | comments welcome! | |
| 20:26:53 | mriedem | efried: that's an implementation detail though isn't it? | |
| 20:27:54 | efried | mriedem: Which, update_provider_tree? I don't think there's any possible interpretation by which that stack of work could be considered just "implementation detail". | |
| 20:27:54 | cdent | thanks edleafe enqueued for tomorrow, currently writing my own | |
| 20:28:38 | mriedem | efried: ok, i guess i need to read your provider tree spec then | |
| 20:28:51 | mriedem | which i thought you said was less of a spec and more just docs of the thing that merged in queens? | |
| 20:29:06 | efried | ...which needed to be specified in some form, yeah. | |
| 20:29:38 | efried | And which didn't quite get finished in queens, and is a big enough piece of work to warrant a bp and spec of its own (at least if it wasn't going to be described in the nrp spec) | |
| 20:31:55 | mriedem | ok, i'll get to new business some other day; was just trying to go through easy re-approvals | |
| 20:32:11 | mriedem | i will mentally note that this isn't an easy re-approval | |
| 20:32:50 | efried | mriedem: Anyway, to tie that back together, I believe update_provider_tree changes the NUMA plan as described around https://review.openstack.org/#/c/505209/7/specs/queens/approved/nested-resource-providers.rst@136 | |
| 20:34:08 | efried | mriedem: Because we're no longer going to be basing anything on get_available_resource. Rather, we'll ask virt to report NUMA topology through update_provider_tree (in some standardized format TBD? Swhat jaypipes and I are debating in https://review.openstack.org/543062) and then deal with the pinning/affinitizing from there. | |
| 20:34:42 | efried | Suspect there will be much PTGing at the PTG about this. | |
| 20:35:01 | mriedem | ok - thinking again about just amending the queens spec, making a note that the spec is just focusing on groundwork stuff, might give examples of use cases, but details for supporting other use cases (sriov/numa) are going to be found in later specs | |
| 20:35:30 | efried | mriedem: Do you want me to propose that edit? | |
| 20:35:36 | mriedem | up to you | |