Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-13
08:54:50 lyarwood https://github.com/openstack/project-config/blob/b393e477951ba3a38c63565c0824f4cf95ae292d/zuul.d/pipelines.yaml#L349-L376 - yeah just found that
08:55:44 lyarwood so I assume we'd need to add that pipeline alongside check etc in .zuul.yml - https://github.com/openstack/nova/blob/554a6ffa837ba915c06c8ae70c339e911c9c9303/.zuul.yaml#L213-L336
08:55:51 lyarwood and define some jobs
08:56:57 lyarwood kevinz: I'd raise this on the weekly meeting later today if you're around.
08:57:06 lyarwood or the ML if you're not
08:58:31 kevinz lyarwood: Thanks, We can talk via ML first. as today's meeting is quite early for me :D
08:58:50 kevinz we should define some jobs for this CI
09:00:36 kevinz lyarwood: The meeting next week(UTC14 is available for me)
09:01:00 lyarwood kevinz: ack understood, well in that case feel free to propose a change and we can always talk about things directly there as well :)
09:01:48 kevinz lyarwood: no problem, I will. Thanks a lot
09:04:10 lyarwood np :)
09:04:43 openstackgerrit Lee Yarwood proposed openstack/nova master: images: Remove Libvirt specific configurable use from qemu_img_info https://review.opendev.org/707591
09:04:43 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Always provide the size in bytes when calling virDomainBlockResize https://review.opendev.org/707590
09:21:20 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM - Test TEMPEST_EXTEND_ATTACHED_ENCRYPTED_VOLUME https://review.opendev.org/707593
10:00:31 huaqiang stephenfin: sean-k-mooney: alex_xu: Thanks for review. And now I just have several things need to further disccuss with you when you are around.
10:16:34 huaqiang sean-k-mooney: for the mixed instance spec, in the cpu policy matrix, when no 'hw:cpu_policy' and 'hw_cpu_policy' defined, I think the final result should not be 'shared', which is you sugguested in your review.
10:17:29 huaqiang because in this case, say again, no 'hw_cpu_policy' in image property and no 'hw:cpu_policy' in flavor extra specs,
10:18:01 huaqiang the final instance CPU allocation policy is determined by 'resources:(P|V)CPU'
10:18:10 huaqiang it might be 'dedicated' or 'mixed'
10:37:55 openstackgerrit Sundar Nadathur proposed openstack/nova master: Delete ARQs for an instance when the instance is deleted. https://review.opendev.org/673735
10:37:56 openstackgerrit Sundar Nadathur proposed openstack/nova master: Enable start/stop of instances with accelerators. https://review.opendev.org/699553
10:37:56 openstackgerrit Sundar Nadathur proposed openstack/nova master: Enable hard/soft reboot with accelerators. https://review.opendev.org/697940
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:57 openstackgerrit Sundar Nadathur proposed openstack/nova master: Enable and use COMPUTE_ACCELERATORS trait. https://review.opendev.org/699554
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.

Earlier   Later