| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 19:31:00 | mriedem | melwitt: it's this http://logs.openstack.org/25/511325/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/5130700/logs/libvirt/qemu/instance-00000004.txt.gz | |
| 19:31:01 | mriedem | known issue | |
| 19:31:06 | mriedem | qemu-system-x86_64: /build/qemu-GGGtkw/qemu-2.8+dfsg/block/io.c:1514: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. | |
| 19:31:20 | melwitt | okay. I looked at it earlier and it's not related to that patch but I hesitated to blindly recheck | |
| 19:31:24 | cdent | efried: yes, so the the migration uuid stuff that dansmith has is not racey | |
| 19:31:35 | melwitt | mriedem: cool, thanks | |
| 19:31:50 | mriedem | melwitt: https://bugs.launchpad.net/nova/+bug/1706377 | |
| 19:31:51 | openstack | Launchpad bug 1706377 in OpenStack Compute (nova) "(libvirt) live migration fails on source host due to "Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed."" [Undecided,Confirmed] | |
| 19:32:03 | mriedem | we can't fingerprint that in e-r because the failure is in the qemu instance logs, which we don't index | |
| 19:32:15 | melwitt | gotcha | |
| 19:34:46 | jaypipes | efried: k, just read the granular resource requests spec. lgtm. | |
| 19:35:10 | efried | jaypipes Cool, thanks for going through it. | |
| 19:35:44 | efried | cdent Is there a patch somewhere that's adding the project_id/user_id to the GET /allocations/{consumer_uuid} response? | |
| 19:36:25 | cdent | yeah, it’s an antecedent to the thing that adds the schema: https://review.openstack.org/#/c/500073/ | |
| 19:36:44 | cdent | sorry wrong paste | |
| 19:36:58 | cdent | https://review.openstack.org/#/c/512420/ | |
| 19:38:25 | mriedem | melwitt: now you just need to find another stable core to approve it :) | |
| 19:38:29 | efried | cdent Okay, and where does the api-ref get updated? | |
| 19:38:40 | efried | cdent This sucker: https://developer.openstack.org/api-ref/placement/#list-allocations | |
| 19:38:58 | mriedem | efried: https://github.com/openstack/nova/tree/master/placement-api-ref/source ? | |
| 19:39:22 | mriedem | or the actual infra that updates the page? | |
| 19:39:47 | cdent | efried: it’s not done yet. I haven’t decided where to put it. Could go in a more generic https://review.openstack.org/#/c/510626/ | |
| 19:40:13 | cdent | efried: so please feel free to put a -1 somewhere in there that says “oi, you’ve not done the docs yet" | |
| 19:40:47 | efried | cdent Okay, cool, that's what I wanted to know. (mriedem specifically the doc change that adds the project/user id to that api-ref piece) | |
| 19:42:12 | cdent | efried: thanks for the attention to detail, the content of that stack has expanded a lot since I started, so some steps have been lost | |
| 19:42:53 | efried | cdent Swhat I'm here for. Eventually I'll be useful for something other than pointing out typos and missed paperwork. | |
| 19:43:22 | dansmith | efried: don't forget rebasing | |
| 19:43:34 | efried | Mm | |
| 19:43:49 | dansmith | you can rebase a mofo like a sonofabee | |
| 19:44:54 | mriedem | sdague: can you get this pike backport and the one below? | |
| 19:45:33 | mlavalle | mriedem: any chance we can get nova team eyes on the lastest revisions of https://review.openstack.org/#/c/375580/ and https://review.openstack.org/#/c/502306/ | |
| 19:45:42 | dansmith | edleafe: cdent: so that limits or {} thing.. limits is nullable in reqspec.. are we sure we need do that thing? | |
| 19:46:02 | dansmith | also, I'm not clear on what part of this series requires this when we didn't before | |
| 19:46:37 | mriedem | mlavalle: honestly i think the bandwidth provider thing is not going to happen in queens | |
| 19:46:45 | mriedem | given the various dependencies and overall complexity | |
| 19:47:39 | mlavalle | mriedem: dependencies meaning functionality that is being developed in the Nova side? | |
| 19:47:45 | mriedem | mlavalle: yes | |
| 19:48:01 | mriedem | there are some major challenges to overcome before we can even get to bandwidth provider | |
| 19:48:56 | mriedem | mlavalle: for example, it relies on the compute pushing the bandwidth allocations and we're moving away from the computes trying to create allocations | |
| 19:53:02 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] manage cache headers for usages https://review.openstack.org/513174 | |
| 19:54:34 | edleafe | dansmith: it caused multiple unit test failures without the 'or {} | |
| 19:54:58 | edleafe | dansmith: not sure if the change back to including limits makes that no longer the case. | |
| 19:55:04 | dansmith | edleafe: lol. well we should put that in the comment then, eh? | |
| 19:55:16 | dansmith | edleafe: I'd like to understand why we're making that change if we are | |
| 19:55:20 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 19:55:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 19:55:22 | jaypipes | efried: fixed. ^ | |
| 19:56:49 | cdent | goodnight all | |
| 19:57:03 | mriedem | gdi i hate reviewing specs in new gerrit | |
| 19:57:14 | mriedem | jumps all over the place when trying to expand comments | |
| 19:57:31 | jaypipes | mriedem: yuuuuup. drives me friggin nuts. | |
| 19:57:49 | mriedem | firefox? | |
| 19:57:58 | jaypipes | yup. | |
| 19:58:08 | edleafe | dansmith: re-running tests with that change reverted - will let you know | |
| 19:58:30 | dansmith | edleafe: thanks | |
| 19:58:38 | dansmith | mriedem: jaypipes not just in firefox | |
| 19:59:11 | dansmith | mriedem: left one nit and one real comment in johnthetubaguy's ironic patch | |
| 19:59:23 | dansmith | I can fix the nit (and the functional bit too I guess) if you agree | |
| 20:01:56 | mriedem | replied | |
| 20:05:42 | dansmith | mriedem: I do it in with statements because python requires it :P | |
| 20:06:33 | dansmith | mriedem: so you think we have no other situations other than moves that ironic doesn't support where we don't want said stomping? | |
| 20:08:07 | mriedem | my brain is kind of fried, | |
| 20:08:16 | mriedem | at this point, you're likely to blow your foot off either way | |
| 20:08:27 | mriedem | because of the minefield i mean | |
| 20:09:06 | mriedem | the stomp was really because of moves from ocata to pike nodes i thought, scheduler would claim on both (double stuff) and ocata periodic would overwrite the allocations created by the scheduler, | |
| 20:09:17 | mriedem | and then the dest node would overwrite the allocations again once the move was done | |
| 20:09:43 | mriedem | you can't resize, live migrate or unshelve an ironic instance | |
| 20:09:54 | mriedem | and with evacuate, the source host isn't running the stomper | |
| 20:11:50 | dansmith | alright | |
| 20:12:05 | mriedem | i could be missing something | |
| 20:12:09 | mriedem | like i said, minefield | |
| 20:12:15 | mriedem | seinfeld minefield | |
| 20:12:43 | mriedem | "what's the deal with all these allocations?!" | |
| 20:14:47 | openstackgerrit | Dan Smith proposed openstack/nova master: Keep updating allocations for Ironic https://review.openstack.org/513085 | |
| 20:15:55 | mriedem | omfg, | |
| 20:16:03 | mriedem | dansmith: jaypipes: change the rendering setting to 'slow' | |
| 20:16:05 | mriedem | seems to help | |
| 20:16:09 | mriedem | smcginnis: ++ | |
| 20:17:19 | smcginnis | mriedem: It helped even more in the last gerrit. This one has some more quirks, but I think it's better. | |
| 20:17:20 | dansmith | I don't even know what that would mean, but... cool | |
| 20:18:00 | mriedem | gerrit settings | |
| 20:18:12 | dansmith | I mean I dunno what fast rendering would be | |
| 20:18:21 | dansmith | it all seems pretty slow to me :) | |
| 20:19:19 | mriedem | they should rename the setting to "stop fucking up my gd cursor placement fucker" | |
| 20:19:20 | mriedem | i agree | |
| 20:20:24 | mriedem | efried: thanks for helping to review this https://review.openstack.org/#/c/502306/ | |
| 20:20:27 | mriedem | it's definitely hairy | |
| 20:20:45 | efried | mriedem phew, thought I was just being dense. | |
| 20:21:19 | smcginnis | mriedem: +1 to that name, it would be much more accurate. | |
| 20:21:23 | mriedem | no man, it's building on like all of the worst things | |
| 20:21:43 | mriedem | port orchestration, nested resource providers, scheduling, neutron agent stuff, etc etc | |
| 20:29:02 | mriedem | sean-k-mooney: in https://review.openstack.org/#/c/502306/ - so when nova binds a port to a selected host, neutron will put some kind of allocation information in the port binding profile, and nova will proxy that allocation information to placement? | |
| 20:29:14 | mriedem | and the suggested flow is: | |
| 20:29:22 | mriedem | 1. conductor asks scheduler for a host | |
| 20:29:51 | mriedem | 2. scheduler filter looks for ports with a qos policy and if found, gets allocatoin candidates for hosts that have a nested bw provider | |
| 20:29:59 | mriedem | 3. scheduler returns host to conductor | |
| 20:30:05 | mriedem | 4. conductor binds the port to the host | |
| 20:30:24 | mriedem | 5. the bound port profile has some allocation juju that nova proxies to placement as an allocation request for the port on the bw provider | |
| 20:30:34 | mriedem | 6. conductor sends to compute to build the instance | |
| 20:30:42 | mriedem | 7. compute activates the bound port | |