| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 16:42:09 | hrw | jaypipes: I am not getting young as well ;D | |
| 16:42:13 | mriedem | has_been_scheduled_or_should_be_in_cell0_or_idk_whatever | |
| 16:48:43 | hrw | https://paste.fedoraproject.org/paste/A9Gtb~sliIFo2-yvA32ymw - preliminary version | |
| 16:50:54 | bauzas | dansmith: I left some comments but only one is blocking me from +2 on https://review.openstack.org/#/c/544585/6 | |
| 16:51:17 | bauzas | dansmith: the fact that I wonder if we should persist the changes in the RequestSpec or not | |
| 16:51:44 | dansmith | bauzas: why wouldn't we? | |
| 16:51:51 | bauzas | maybe it's just an implementation detail, but we've seen in the past some problems with the RequestSpec fields that were badly designed whether they should be persisted or not | |
| 16:52:05 | mriedem | like instance groups? | |
| 16:52:05 | bauzas | dansmith: for the usecase you described, I agree | |
| 16:52:26 | dansmith | bauzas: we'll re-run the pre filters on reschedule, so persisted data could be kept, re-evaluated, updated, etc | |
| 16:52:37 | bauzas | dansmith: but since we'll define a modular mechanism, we could end up having cases where it's necessary and some not | |
| 16:52:49 | bauzas | dansmith: that answer suits me | |
| 16:53:03 | dansmith | yeah, each one could do a different thing with the persisted data | |
| 16:53:07 | mriedem | yeah we'd definitely need this for any move operations | |
| 16:53:16 | bauzas | dansmith: we could persist that, but we shouldn't use that value on a later reschedule but rather recalculate it | |
| 16:53:31 | bauzas | that being a per-filter policy | |
| 16:53:33 | dansmith | bauzas: depends | |
| 16:53:35 | dansmith | yeah | |
| 16:53:37 | dansmith | I will reply | |
| 16:53:41 | bauzas | cool | |
| 16:53:44 | bauzas | one last point | |
| 16:53:46 | bauzas | but it's a nit | |
| 16:53:54 | bauzas | I'm poor at wording | |
| 16:54:08 | bauzas | but I'm afraid the word "filter" carries a lot of context | |
| 16:54:27 | bauzas | so I'd prefer to use a synonym for that mechanism | |
| 16:54:33 | bauzas | I know it's sneaky | |
| 16:54:50 | bauzas | so feel free to NACK me | |
| 16:54:52 | dansmith | bauzas: it's not exposed as a filter to the user or admin at all | |
| 16:55:06 | dansmith | bauzas: so we can change it either now or later if it becomes a problem | |
| 16:55:19 | bauzas | yeah it's just wording | |
| 16:55:26 | dansmith | but, IMHO, it's not a big enough deal to rename the things I have already :) | |
| 16:55:31 | bauzas | like we have nova aggs and placement aggs | |
| 16:55:41 | bauzas | dansmith: not requiring a respin of your spec | |
| 16:55:57 | bauzas | dansmith: but maybe we should consider that in your series :) | |
| 16:56:13 | dansmith | bauzas: well feel free to take exception to it in the code if you still feel that way yeah | |
| 16:56:16 | bauzas | scheduler filters and request filters seem very identical to me in terms | |
| 16:56:51 | bauzas | again, it's maybe me overreacting on some blueprints I could see in the future | |
| 16:57:07 | dansmith | what word do you like better? | |
| 16:57:10 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe slots in aarch64 instance https://review.openstack.org/545034 | |
| 16:57:28 | hrw | cna someone take a look at that patch? mriedem stephenfin bauzas? | |
| 16:57:40 | bauzas | dansmith: from a French folk, the Thesaurus tells me "strain" | |
| 16:57:54 | dansmith | lol | |
| 16:57:55 | bauzas | but anyway, I feel ashamed of nitpicking on that | |
| 16:58:06 | dansmith | that would make no sense to an english speaker | |
| 16:58:18 | bauzas | the history of nova told me that there are 3 NP problems | |
| 16:58:26 | bauzas | distibuted locks | |
| 16:58:36 | bauzas | NFV | |
| 16:58:41 | bauzas | or BFV even | |
| 16:58:44 | bauzas | and naming things | |
| 16:59:00 | bauzas | naming a new thing requires 3 cycles at least | |
| 16:59:21 | bauzas | in order to get consensus | |
| 16:59:37 | bauzas | so, anyway, let's just pretend I never asked for that | |
| 16:59:46 | dansmith | bauzas: as the only one who has (thus far) taken exception with the name, it's funny for you to be complaining about that :) | |
| 17:00:11 | bauzas | I know, hence my apologies | |
| 17:00:22 | bauzas | let's pretend that discussion never existed | |
| 17:00:35 | bauzas | (17:57:55) bauzas: but anyway, I feel ashamed of nitpicking on that | |
| 17:02:12 | mriedem | hrw: busy atm, can you mark that WIP if it's the initial version w/o tests? | |
| 17:02:19 | hrw | mriedem: ok | |
| 17:02:56 | hrw | W-1 | |
| 17:04:27 | openstackgerrit | Merged openstack/nova master: Don't JSON encode instance_info.traits for ironic https://review.openstack.org/543574 | |
| 17:04:44 | openstackgerrit | Merged openstack/nova master: Python 3 fix for sphinx doc https://review.openstack.org/544956 | |
| 17:05:51 | mriedem | ameeda: i think you're missing a unit test in https://review.openstack.org/#/c/528385/ | |
| 17:06:18 | mriedem | otherwise i think that's mostly ok, outside of the commit message cleanup | |
| 17:06:27 | openstackgerrit | Mark Goddard proposed openstack/nova stable/queens: Don't JSON encode instance_info.traits for ironic https://review.openstack.org/545037 | |
| 17:22:14 | mriedem | stephenfin: i don't know what people want in here https://review.openstack.org/#/c/544015/ | |
| 17:22:37 | bauzas | mriedem: dansmith: edleafe: cdent: I'm about to +W https://review.openstack.org/#/c/544585/ | |
| 17:22:46 | bauzas | if anyone has concerns, that's the moment | |
| 17:22:58 | bauzas | oops, jaypipes too ^ | |
| 17:23:57 | dansmith | my only concern would be the dependent specs, if people want those landed first | |
| 17:24:01 | dansmith | but I don't mind either way really | |
| 17:24:55 | stephenfin | mriedem: I think you identified what he was looking for, which was different to what I thought. Given that the caching scheduler is deprecated (I didn't know that), we don't need to worry about IMO | |
| 17:25:42 | mriedem | bauzas: it is certainly possible to know if we're doing a first schedule or a reschedule, | |
| 17:25:48 | mriedem | RequestSpec.retry has that information | |
| 17:26:00 | bauzas | mriedem: for a reschedule yes | |
| 17:26:05 | bauzas | mriedem: for a move operation, nope | |
| 17:26:08 | edleafe | bauzas: that's cool. At least there has been some discussion since my comment | |
| 17:26:11 | mriedem | bauzas: that's because https://review.openstack.org/#/c/505771/ | |
| 17:26:49 | mriedem | well, the issue in ^ confuses the fact that you're doing a reschedule or a move | |
| 17:26:57 | bauzas | shit | |
| 17:27:26 | bauzas | how many times will I regret to not have thought more on persisted fields for the RequestSpec object ? | |
| 17:27:47 | openstackgerrit | Claudiu Belu proposed openstack/nova master: compute: Cleans up allocations after failed resize https://review.openstack.org/543971 | |
| 17:27:57 | jaypipes | bauzas: hold please. | |
| 17:27:58 | cdent | bauzas: feel free to +w the spec if there's been enough feedback | |
| 17:28:00 | jaypipes | still reviewing | |
| 17:28:01 | mriedem | i thought that would be an easy fix but then second guessed myself, and need to write a functional test to be sure | |
| 17:28:07 | cdent | bauzas: except for jay :) | |
| 17:28:26 | bauzas | jaypipes: ack | |
| 17:29:52 | efried | Could rebase it on top of the other spec | |
| 17:31:29 | dansmith | or someone could slam it in: https://review.openstack.org/#/c/544694/ | |
| 17:31:42 | dansmith | it's really simple, has a lot of +1s from stakeholders and only needs a +W | |
| 17:31:50 | mriedem | looking | |
| 17:32:04 | mriedem | i will ram this down your throat like obamacare to the republicans | |
| 17:32:18 | mriedem | lemme call nancy quick | |
| 17:32:25 | dansmith | lolol | |
| 17:33:01 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057 | |
| 17:34:21 | dansmith | apparently by "lots" I meant "two" but.. you know | |
| 17:34:53 | mriedem | consider it rammed | |
| 17:35:03 | mriedem | thanks obama | |
| 17:35:19 | mriedem | the two that matter | |
| 17:38:51 | jaypipes | dansmith: cern doesn't use the cachingscheduler does it? | |