| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-13 | |||
| 13:03:46 | sean-k-mooney | ok ill leve it up to you to decide | |
| 13:04:34 | sean-k-mooney | regarding whitebox stephenfin i think you will agree it is a nice to have but not a hard requirement | |
| 13:05:13 | sean-k-mooney | form a downstream perspective we will need to have this tested with whitbox before we can support it in the osp product but it should not be a requirement for merging upstream | |
| 13:05:30 | sean-k-mooney | espcially since we dont currently have a whitebox job runing against nova | |
| 13:06:45 | alex_xu | sean-k-mooney: thanks | |
| 13:15:38 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test TEMPEST_EXTEND_ATTACHED_ENCRYPTED_VOLUME https://review.opendev.org/707593 | |
| 13:24:36 | gibi | cores, volume local cache discussion will start soon on https://bluejeans.com/3228528973 | |
| 13:24:48 | gibi | or even anybody who is interested | |
| 13:32:52 | gibi | sean-k-mooney: ^^ | |
| 13:38:27 | stephenfin | efried, gibi, dansmith: API question: should the `validation` parameter for the extra spec validation be part of the POST/PUT request body or the query string? | |
| 13:38:59 | stephenfin | we seem to do the former for things like server hints https://docs.openstack.org/api-ref/compute/?expanded=create-extra-specs-for-a-flavor-detail,create-server-detail#id11 | |
| 13:41:01 | mnaser | just wondering if we can have more eyes on: https://review.opendev.org/#/c/670112/ -- its really helpful and still remains useful to this day :> | |
| 13:41:07 | sean-k-mooney | stephenfin: query arg | |
| 13:41:10 | sean-k-mooney | i think | |
| 13:41:31 | sean-k-mooney | although if we dont have other args in the query args | |
| 13:41:39 | sean-k-mooney | then maybe the body | |
| 13:41:58 | sean-k-mooney | query arg fells more natural | |
| 13:42:40 | sean-k-mooney | as its not part of the data of the flavor resouces | |
| 13:44:04 | stephenfin | Hmm, yeah, you could make the same argument for server hints though | |
| 14:06:48 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924 | |
| 14:10:59 | bauzas | efried: dansmith: gibi: sean-k-mooney: stephenfin: ^ | |
| 14:25:11 | openstackgerrit | Merged openstack/nova master: Make RBD imagebackend flatten method idempotent https://review.opendev.org/704330 | |
| 14:29:51 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Make RBD imagebackend flatten method idempotent https://review.opendev.org/707650 | |
| 14:38:18 | huaqiang | sean-k-mooney: thanks. I have removed the content of white-box and send the spec agian. | |
| 14:39:34 | openstackgerrit | Huachang Wang proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 14:40:43 | huaqiang | stephenfin: sean-k-mooney: alex_xu: the mixed instance spec is updated, please review. Thanks | |
| 14:52:43 | dansmith | stephenfin: agree query arg feels more right-er | |
| 15:10:00 | efried | stephenfin: I vote qparam too. | |
| 15:10:13 | stephenfin | sweet. qparam it is | |
| 16:16:32 | gibi | stephenfin: I vote for query arg as Sean stated it is not part of the entity you actually create or modify | |
| 16:21:10 | efried | bauzas: I'm very close on the NUMA RP spec; +2 if you just flip the defaults as noted. But (despite him saying he's not blocking) I want to convince stephenfin that this is the way we should go. | |
| 16:21:46 | efried | sean-k-mooney: do you agree with my notes on the default for implicit numa nodes? | |
| 16:22:00 | efried | https://review.opendev.org/#/c/552924/20/specs/ussuri/approved/numa-topology-with-rps.rst@269 | |
| 16:24:31 | stephenfin | efried: So I'm clear, what's the objection to a "I want this host to report/not report NUMA"? | |
| 16:24:35 | stephenfin | dansmith too ^ | |
| 16:24:57 | efried | stephenfin: no objection. That's being provided. But I want the default to be "report NUMA". | |
| 16:25:39 | stephenfin | It's being provided temporarily though, not long term | |
| 16:25:44 | stephenfin | Why not do this long-term | |
| 16:25:50 | efried | ah, okay: | |
| 16:27:24 | efried | The way dansmith explained it, the only reason we don't always report NUMA and create real NUMA topologies for guests is because it's hard. But no consumer *actually* wants a guest that doesn't affine its memory to CPUs; they're taking a significant performance hit because we haven't solved this problem in nova. | |
| 16:27:38 | efried | I'm... paraphrasing. Dan was more eloquent about it. | |
| 16:27:53 | dansmith | doubtful, but yeah | |
| 16:27:56 | efried | But we have to balance that against fitting. | |
| 16:28:24 | dansmith | stephenfin: I don't want to have two "modes" for the compute service to operate in long term | |
| 16:28:47 | efried | again paraphrasing dansmith, nova explicitly disclaims the ability to fit that last VM on that last almost-full host. So if we're compromising, that's where we're compromising. | |
| 16:29:04 | stephenfin | But we could provide NUMA information to the guest. It would just match the topology of the host | |
| 16:29:13 | efried | that's exactly what we're doing. | |
| 16:29:24 | efried | the U proposal does it imperfectly, 80/20. | |
| 16:29:33 | efried | For V we can work on can_split to get that other 20% | |
| 16:29:39 | efried | and then we can remove the [workaround]. | |
| 16:30:46 | stephenfin | From the the libvirt XML perspective, yeah, but not from placement perspective | |
| 16:31:08 | efried | sorry, wha? | |
| 16:34:18 | stephenfin | The only guests that *needs* NUMA affinity are pinned instances, yeah? | |
| 16:34:39 | stephenfin | and those with hugepage, but that's a self-inflicted wound | |
| 16:35:15 | stephenfin | the pinned ones need it because their cores are pinned to host cores from a specific NUMA node | |
| 16:35:42 | stephenfin | whereas unpinned instances are floating across all (enabled) host cores | |
| 16:36:01 | stephenfin | so they naturally have affinity to everything, even though we don't properly expose that information to the guest | |
| 16:37:16 | efried | does memory float too? | |
| 16:37:37 | stephenfin | if you don't provide a pagesize, yes | |
| 16:37:48 | stephenfin | but otherwise, no. that's the self-inflicted wound I talked about above | |
| 16:38:24 | efried | Then why are we modeling 4k pages under NUMA nodes? | |
| 16:38:47 | efried | Wait, *can* you pin 4k pages? | |
| 16:39:03 | stephenfin | I _think_ so, yeah | |
| 16:39:12 | stephenfin | if you use the strict mem policy | |
| 16:39:32 | stephenfin | actually, I don't think it's pinning in the traditional sense | |
| 16:39:36 | stephenfin | because they can be shared | |
| 16:40:15 | stephenfin | sorry, I'm in a meeting so I can't formulate my thoughts properly. gimme 20 | |
| 16:42:50 | efried | Ight. I don't have the depth of understanding to refute the "unpinned/floating" argument, which I was kinda advocating the other day (albeit probably without specifics). Going to need dansmith to take that on. | |
| 16:45:03 | dansmith | I think maybe he's talking about the case where you're overcommitting memory | |
| 16:47:33 | dansmith | I'm also really not an expert on the low-level details, so maybe we've gotten lost in the woods a bit, | |
| 16:49:52 | efried | tobiash: What's the word on https://review.opendev.org/#/c/572805/ ? Spec freeze is today. | |
| 16:50:03 | dansmith | I'm trying to translate what I know of reports of what people do, vs. what they would like to do, and what makes sense into what we should be doing | |
| 16:51:19 | tobiash | efried: sorry, I was busy with other other things in the meantime, I fear it has to be postponed to the next release :( | |
| 16:51:34 | efried | tobiash: Okay, thanks, I'll do that. | |
| 16:51:41 | tobiash | thanks a lot | |
| 16:59:51 | bauzas | efried: sorry, was on meeting | |
| 17:00:42 | efried | bauzas: I really just want to know what you think of my French | |
| 17:01:03 | bauzas | LOL | |
| 17:01:29 | gibi | efried: based on Tushar's comment on the spec bp/support-shared-storage-resource-provider can be deferred out from U | |
| 17:02:05 | bauzas | efried: we have some french continuous present but not really like yours | |
| 17:02:39 | efried | no, like I said, I don't see anybody ever saying or writing anything like that. | |
| 17:02:41 | bauzas | efried: anyway, I see your -1 but I intentionnally flipped the default to *not* reshape as discussed between sean-k-mooney, stephenfin and I | |
| 17:02:59 | efried | bauzas: to me, that's the crux | |
| 17:03:10 | efried | If we don't reshape by default, everything changes. | |
| 17:03:13 | bauzas | efried: because of the potentiality of the regressions we could get | |
| 17:03:15 | bauzas | efried: I know | |
| 17:03:23 | bauzas | efried: and I wanted to discuss this with you | |
| 17:03:52 | bauzas | because I'm very afraid of any potential issue we would have in Ussuri | |
| 17:03:59 | efried | stephenfin and dansmith need to be involved, but I think they're are on calls rn | |
| 17:03:59 | bauzas | if we flip to changing the world | |
| 17:04:22 | bauzas | my point is, I don't know the figure but not all clouds care about NUMA | |
| 17:04:37 | bauzas | for those clouds, I'd prefer us to not change their lifes | |
| 17:04:51 | bauzas | and pretending there will be no regressions | |
| 17:05:07 | efried | So dansmith's argument was "don't care about NUMA" does *not* mean "give me shitty performance". | |
| 17:05:24 | bauzas | on the other hand, if we allow a default to be "no-op", then we can work on the NUMA implementation seamlessly and iteratively like we did for Cells v2 | |
| 17:05:27 | efried | The [workaround] and reversible reshape gives you the way to deal with regressions. | |
| 17:05:29 | dansmith | I don't really understand.. I thought the agreement was to default the new behavior off for U, not reshape by default, let people opt-in during U and then flip the default (or remove it) for V? | |
| 17:05:55 | efried | ugh, no, if we were doing that, there would be no good motivation to hack the splitting thing in. | |
| 17:06:02 | efried | And also no motivation for operators to opt in. | |
| 17:06:07 | efried | so it would be a waste of effort. | |