| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 19:05:38 | mriedem | dansmith: this newton backport of artom's looks good to me now https://review.openstack.org/#/c/471356/ - it's kind of a frankenpatch with squashes but does the job | |
| 19:05:48 | mriedem | would be the last one for newton before we release and tag for eol | |
| 19:07:00 | efried | jaypipes And as soon as you come up for air, would like your input on the possibility of ripping out some of the existing aggregate code until we can figure out how tf it's ever going to work with traits & nested & numbered. | |
| 19:08:03 | jaypipes | efried: well, on that, if it isn't currently affecting anything (other than read queries which cdent has patches up to address perf issues), I'd just as soon leave it be for now. We have lots of other things to get done by SYD | |
| 19:08:20 | dansmith | yeah | |
| 19:08:22 | dansmith | me too | |
| 19:08:28 | efried | jaypipes That's just it: it very well may be affecting "things". | |
| 19:10:14 | jaypipes | efried: well, I'm perfectly happy to see your thoughts on it. just not a huge priority unless you can show me it's causing bugs. | |
| 19:10:33 | jaypipes | efried: besides the general "tech debt bugs" which I certainly admit there are many. | |
| 19:10:47 | jaypipes | ok, lemme read this granular spec :) | |
| 19:13:28 | mriedem | dansmith: john put up a patch for the ironic flavor migratoin allocatoins thing https://review.openstack.org/#/c/513085/2 | |
| 19:13:40 | mriedem | seems ok to me | |
| 19:14:24 | dansmith | mriedem: yeah, sorry, I'm just behind | |
| 19:14:32 | mriedem | np, i just got back from running errands | |
| 19:15:13 | mriedem | your context targeting thing in pike is also happy for ci now https://review.openstack.org/#/c/512456/ | |
| 19:15:28 | mriedem | sdague: ^ we need to get that released soon | |
| 19:16:50 | dansmith | okay I can hit that one quick | |
| 19:16:54 | dansmith | because I know it's perfect | |
| 19:17:00 | mriedem | :) | |
| 19:21:09 | sdague | mriedem: yeh, that seems fine. I wasn't originally sure that the sc reinflates over that, but it looks like it does | |
| 19:26:21 | efried | cdent What was the thing where you could modify an allocations/{consumer_uuid} - is that gonna be via PUT or POST? | |
| 19:26:24 | melwitt | mriedem: have you seen live migration job fails like this before? raises InstanceNotFound because of VIR_ERR_NO_DOMAIN? https://github.com/openstack/nova/blob/stable/ocata/nova/virt/libvirt/host.py#L553 | |
| 19:26:42 | cdent | efried: that’s always PUT, and it always replaces | |
| 19:27:04 | cdent | the post version is in progress at: https://review.openstack.org/#/c/500073/ | |
| 19:27:15 | efried | cdent Okay. I'm looking at your schema here https://review.openstack.org/#/c/510625/7/nova/api/openstack/placement/handlers/allocation.py and I think it's a little strict. Will see if you "fixed" it via ^. | |
| 19:27:31 | melwitt | mriedem: the "target build notification" patch for ocata failed the live migration job on that and I was wondering if it's just something to recheck or if it's something more | |
| 19:28:08 | cdent | efried: strict how? (entirely possible my jsonschema fu doesn’t allow for handstands) | |
| 19:28:56 | efried | cdent I think you might have done it, but still pondering. Basically by saying minProperties=1 in a couple places, you would be disallowing resources: {} which was (I thought) how you would say you're deleting those pieces of the allocation. | |
| 19:29:12 | efried | Though I guess omitting that chunk entirely would also work, since it's replacing. | |
| 19:29:17 | efried | So maybe moot. | |
| 19:29:36 | cdent | minProperties is disallowing anything other than the resource provider keyed object | |
| 19:30:09 | cdent | which is required on PUT, but will not be required on POST | |
| 19:30:36 | mriedem | melwitt: was just looking at that one | |
| 19:30:58 | efried | cdent So what's the POST supposed to do? Oh, allow you to modify allocations for multiple consumers at once? | |
| 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 | |