Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-13
12:22:06 stephenfin but I don't see any for 'supports_pcpus'
12:22:35 stephenfin what's the advantage of the trait approach?
12:22:44 stephenfin (for my own reference)
12:23:56 alex_xu sean-k-mooney: that is good point. I didn't think about it. I agree with mix hypervisor, that is useful
12:25:32 alex_xu sean-k-mooney: we have hypervisor doesn't support NUMA right?, but we don't have traits for them also
12:26:41 alex_xu stephenfin: we needn't supports_cpus, probably we need supports_dedicated, or support_numa, I think we have some of hypervisor doesn't support those
12:35:03 sean-k-mooney alex_xu: we do although numa with sylvains spec would be relected in the toplogy of the RPs
12:35:13 sean-k-mooney so it would no longer need it
12:35:22 alex_xu ah, right
12:35:35 sean-k-mooney numa is supported by hyper-v and libvirt today
12:40:49 alex_xu sean-k-mooney: I guess libvirt is the only virt driver report pcpu
12:46:29 huaqiang sean-k-mooney: about the white-box test, it was the decision made on Shanghai PDT meeting, I need stephenfin's openion
12:47:37 huaqiang If I remember correctly, he proposed the test. I'd know if he insists on the same openion now
12:49:11 huaqiang stephenfin: If I'll add functional tests for the proposing mixed instance spec, do you still think the white-box tempest plugin should be a test that I have to pass?
12:51:01 huaqiang s/add functional tests/add functional tests in intree NUMA test cases/
12:55:00 alex_xu sean-k-mooney: I still prefer service version now. Since it is the legacy way to figure out the upgrade status. And the trait support_mix doesn't useful, since libvirt is the only driver support pcpu. So it doesn't feel good we add extra trait in the placement request which need extra filtering and db query inside placement, but it isn't very useful for now. Maybe we need that trait in the future, if
12:55:02 alex_xu we have other virt driver support pcpu and vcpu on the same host.
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

Earlier   Later