| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 18:44:43 | edmondsw | but didn't fail the test | |
| 18:44:50 | edmondsw | was just on cleanup | |
| 18:45:25 | mriedem | is there no way to have a test for this fix? | |
| 18:46:54 | edmondsw | mriedem yeah, good point... I'd asked esberglu to look at test but then had a brain fart when reviewing I guess | |
| 18:47:27 | mriedem | pew | |
| 18:48:29 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Re-propose use Neutron's new port binding API https://review.openstack.org/543578 | |
| 18:50:31 | mriedem | efried: want to re-propose this for rocky? https://review.openstack.org/#/c/505209/ | |
| 18:51:48 | openstackgerrit | Dan Smith proposed openstack/nova master: Drop compute RPC 4.x compatibility https://review.openstack.org/543580 | |
| 18:52:35 | jaypipes | dansmith, mriedem: https://etherpad.openstack.org/p/going-the-distance has ideas about the distance concept... | |
| 18:52:48 | mriedem | nice pad name | |
| 18:53:26 | mriedem | dansmith: you want to -W that rpc change until we release so someone doesn't accidentally merge it? | |
| 18:53:52 | dansmith | mriedem: rc1 is tagged so we're good no? | |
| 18:54:21 | mriedem | i don't know if we'll have something that requires a backport before GA | |
| 18:54:39 | dansmith | I'm going to argue against that really hard, | |
| 18:54:42 | openstackgerrit | Merged openstack/nova master: doc: mention that --on-shared-storage is not needed with nova evacuate https://review.openstack.org/542512 | |
| 18:54:47 | dansmith | but also, it won't invalidate this | |
| 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/ | |