Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-15
16:36:21 hrw jaypipes: int5 even ;D and I know that python is typeless
16:37:02 jaypipes hrw: it's int5 today. I'm sure a certain hardware manufacturer will change that at some point in the future...
16:38:10 hrw jaypipes: have nothing against it in real hw
16:38:26 hrw jaypipes: there are cpus with >32 pcie lines so it is (in theory) possible
16:38:47 jaypipes hrw: yup.
16:39:24 hrw jaypipes: I remember time when my arm64 machine boot was ~13 minutes due to pci bus scanning
16:40:09 mriedem mnaser: you magnificent bastard, you clarified my big sticking point in melwitt's patch,
16:40:35 mriedem the main thing is that when the instance is in cell0, instance.host is None but the vm_state is ERROR, so we don't enter that first block of code because "if not has_been_scheduled" is False
16:40:47 jaypipes hrw: I remember a time when we weren't coding hardware-defined software ;)
16:40:53 mriedem and the context is targeted at cell0 because the api code does that when we pull the instance out of cell0
16:40:59 mriedem so we can get bdms using that context too
16:41:18 mnaser mriedem: i won't take credit, i had the same train of thought, and melwitt corrected me :p
16:41:43 mriedem the has_been_scheduled variable name is confusing i think
16:41:50 mriedem but i don't have a better alternative
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 :)

Earlier   Later