Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-13
10:37:57 openstackgerrit Sundar Nadathur proposed openstack/nova master: Enable and use COMPUTE_ACCELERATORS trait. https://review.opendev.org/699554
10:37:57 openstackgerrit Sundar Nadathur proposed openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls. https://review.opendev.org/704227
10:37:58 openstackgerrit Sundar Nadathur proposed openstack/nova master: Add cyborg tempest job. https://review.opendev.org/670999
10:39:03 bauzas stephenfin: sean-k-mooney: thanks for the comments on https://review.opendev.org/#/c/552924/, I'll try to update the spec by today around 2pm CET
10:47:47 alex_xu stephenfin: I reply about the image metadata, but we don't have any specific usecase for images meta, I'm just thinking the generic usecase we may have in the nova https://review.opendev.org/#/c/668656/19/specs/ussuri/approved/use-pcpu-vcpu-in-one-instance.rst@122. So i'm not insis on that. just try to ensure that isn't what we want
10:49:00 alex_xu sean-k-mooney: I'm prefer the service version, since I think the traits will become useless after upgrade. And this isn't a feature we have to support in the middle of upgrade. https://review.opendev.org/#/c/668656/19/specs/ussuri/approved/use-pcpu-vcpu-in-one-instance.rst@348
10:49:18 alex_xu huaqiang: ^
11:25:33 openstackgerrit Liang Fang proposed openstack/nova-specs master: Support volume local cache https://review.opendev.org/689070
11:58:40 stephenfin alex_xu: Need to read your reply for the image metadata bit, but for traits vs. service version, by traits do you mean capabilities?
11:59:02 stephenfin i.e. this virt driver can create/handle mixed instances
11:59:05 sean-k-mooney alex_xu: i just added a reason to keep the trait
11:59:47 sean-k-mooney alex_xu: specificaly if you have mixed hypervisors e.g. hyper-v and libvirt the compute campaltibity trait will be useful to select just the libvirt hosts via placement
12:00:34 sean-k-mooney alex_xu: huaqiang: stephenfin ^ what do you think is that enough reason to use the trait
12:01:08 sean-k-mooney stephenfin: we have standardised compute capablitys as traits in os-tratis
12:01:40 sean-k-mooney stephenfin: so when we add a new compute capability we now also add a trait for that
12:03:06 sean-k-mooney basically that is what the compute namespace is for. not entirly but more or less https://github.com/openstack/os-traits/tree/master/os_traits/compute
12:03:46 sean-k-mooney for example the COMPUTE_VOLUME_MULTI_ATTACH trait https://github.com/openstack/os-traits/blob/master/os_traits/compute/volume.py#L24
12:05:30 sean-k-mooney or same host cold migrate for vsphere https://github.com/openstack/os-traits/blob/master/os_traits/compute/__init__.py#L30 i think mix cpu suport makes sense as it not otherwise discoverable via plamcent and i think it is something we want to schdule on
12:07:21 sean-k-mooney alex_xu: with that said i wont -1 if you dont add the trait and decied to go with the service version bump i just dont like useing the service version as a proxy for specific features if we can avoid it.
12:21:42 stephenfin sean-k-mooney: not all of them though
12:21:56 stephenfin we have traits for e.g. the 'supports_image_type_ploop' capability
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?

Earlier   Later