Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-06
10:48:23 artom Aha, ok
10:48:53 artom Confirms what I was seeing in the code, thanks
10:49:03 sean-k-mooney we only generate the cputune element if you have pinning nebaled which give you a numa toplogy
10:49:16 sean-k-mooney we do generate numatune without cpu tune i think
10:49:26 sean-k-mooney e.g. if you just enable hugepages but no pinning
10:49:32 sean-k-mooney or hw:numa_nodes=X
10:50:23 artom sean-k-mooney, you sure? It would happen only if https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4609 doesn't iterate at all
10:50:52 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree https://review.opendev.org/678454
10:50:52 sean-k-mooney we definitly numa affine hugepages
10:50:53 openstackgerrit Luyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec https://review.opendev.org/678456
10:50:53 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup https://review.opendev.org/678455
10:50:54 openstackgerrit Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470
10:50:54 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/679640
10:50:55 openstackgerrit Luyao Zhong proposed openstack/nova master: doc: attaching virtual persistent memory to guests https://review.opendev.org/680300
10:51:10 sean-k-mooney im just not sure if we use vcpupin to pin the cores to the numa node or cpuset
10:51:12 artom sean-k-mooney, right, I'm saying in those cases we also affine guest CPUs with cputune
10:51:19 sean-k-mooney ah ok
10:51:34 sean-k-mooney well as i said cpuset is just a shortcurt for vcpupin
10:51:43 sean-k-mooney let me give an example
10:52:28 sean-k-mooney those are the same
10:52:31 sean-k-mooney <vcpu placement='static' cpuset="1-4" current="1">2</vcpu>
10:52:33 sean-k-mooney <cputune>
10:52:35 sean-k-mooney <vcpupin vcpu="0" cpuset="1-4"/>
10:52:37 sean-k-mooney <vcpupin vcpu="1" cpuset="1,2,3,4"/>
10:52:39 sean-k-mooney <cputune>
10:52:54 sean-k-mooney libvirt internally generate the vcpupin element form the cpu set
10:53:04 sean-k-mooney and generge the same qemu commandline
10:53:12 artom Wait a second.
10:53:24 artom My *entire* code triggers if the instance has a NUMA topology
10:53:32 sean-k-mooney yes
10:53:53 artom So the insance with no NUMA topology on a host with vcpu_pin_set case will have to...?
10:54:12 sean-k-mooney you will need to add support for it
10:54:22 sean-k-mooney well you or stepen
10:54:30 sean-k-mooney technically this is a long standing issue
10:54:43 sean-k-mooney we always should have been updating the xml
10:54:54 sean-k-mooney it will be fixed via a hard reboot however
10:55:15 sean-k-mooney libvirt will reject the migration if the cores do not exist on the dest
10:55:25 artom Right, true
10:55:33 artom I'm surprised more people haven't been hitting that
10:55:54 openstackgerrit Brin Zhang proposed openstack/nova master: Follow-up: Add delete_on_termination to volume-attach API https://review.opendev.org/680655
10:56:05 sean-k-mooney well the havent be casue we tell peole ot use the same cpu_set on all host in teh same aggreagte/az
10:56:11 stephenfin artom: You wouldn't see an issue if you had the same hardware and the same vcpu_pin_set on all hosts
10:56:15 stephenfin yeah
10:56:42 aspiers sean-k-mooney: I've implemented your suggestions from yesterday in https://review.opendev.org/#/c/680065/ and https://review.opendev.org/#/c/644565/
10:56:48 sean-k-mooney and as i said since its fixed on a hard reboot sicne we dont claim anything and just regenreate it form the config
10:57:02 sean-k-mooney aspiers: did it fix the import loop?
10:57:06 aspiers sean-k-mooney: yes
10:57:10 sean-k-mooney :)
10:57:16 stephenfin sean-k-mooney: Has https://blueprints.launchpad.net/nova/+spec/image-metadata-prefiltering been punted to U?
10:57:17 aspiers sean-k-mooney: it worked very nicely as you should see from the comments I just posted
10:57:25 stephenfin If so, can I kick it out of the runway?
10:57:50 sean-k-mooney stephenfin: so i was suggesting since your code and aspiers keeps breaking it
10:57:56 sean-k-mooney and no one is revieing it
10:58:10 stephenfin I was, in fairness
10:58:21 sean-k-mooney that we could kick it out to get your stuff landed instead
10:58:22 aspiers sean-k-mooney: I'm hoping SEV is now done
10:58:50 aspiers all feedback should be now addressed, even stephenfin's request for extra API checks
10:58:51 sean-k-mooney stephenfin: well yes but you wer also reviing the sev stuff which keeps breaking it
10:59:00 stephenfin True
10:59:13 sean-k-mooney i had hoped that it would merge before either the cpu or sev stuff starte merging to avoid that
10:59:26 sean-k-mooney so im ok with punting ot U
10:59:32 sean-k-mooney we did it internally
10:59:42 sean-k-mooney or i can rebase and we can merge it quickly
11:00:07 stephenfin I was going to suggest rebasing on top of cpu-resources and I'd review
11:00:09 stephenfin since it's small
11:00:14 stephenfin but just on master could be fine too
11:00:28 sean-k-mooney erric alredy -2'd it since i said he could
11:00:32 stephenfin the merge conflicts should be slight
11:00:34 sean-k-mooney so ill kick it out of the run way
11:00:40 sean-k-mooney stephenfin: they are
11:01:01 aspiers stephenfin: the list of SEV patches got slightly bigger but don't be fooled, it's just 2 trivial extra refactorings plus the API checks you requested
11:02:01 sean-k-mooney stephenfin: focus on the sev series and your own
11:04:22 aspiers sean-k-mooney: hopefully there will be no more major changes to SEV to cause further merge conflicts
11:05:10 sean-k-mooney aspiers: sev conflict with the cpu series i think
11:05:29 sean-k-mooney but we should finish the sev seires as soon as we can i think
11:05:38 aspiers +1 for that ;-)
11:05:38 sean-k-mooney then push to land the cpu series
11:06:02 aspiers It's unfortunate that there was a Gerrit issue causing the current Zuul backlog
11:06:17 aspiers But hopefully it should catch up over the weekend
11:14:23 bauzas aspiers: gtk, then we should avoid asking for respins in case of nits
11:14:58 aspiers bauzas: yes, currently some jobs are in the check queue for >20 hours
11:16:51 gibi aspiers: I think those jobs stuck, as other, newly proposed patches went through
11:17:27 aspiers gibi: hrmm :-( I'll ask on #openstack-infra
11:19:00 aspiers gibi: Which ones do you see going through which are newer? I don't see them
11:19:07 openstackgerrit Brin Zhang proposed openstack/nova master: Add operator user_id/project_id to the migrations https://review.opendev.org/679413
11:19:07 openstackgerrit Brin Zhang proposed openstack/nova master: Add user_id and project_id colume to Migration https://review.opendev.org/673990
11:19:08 openstackgerrit Brin Zhang proposed openstack/nova master: Filter migrations by user_id/project_id https://review.opendev.org/674243
11:19:45 gibi aspiers: bauzas approved this couple of hours ago https://review.opendev.org/#/c/656422/
11:20:06 gibi aspiers: and it went through the gate since
11:20:58 bauzas but the flakey network makes me crazy
11:21:01 bauzas dudes, move out my lawn !
11:21:28 bauzas (and don't take all bandwith for crazy netflix thingies)
11:21:29 aspiers gibi: but the most recent patch set was uploaded yesterday afternoon
11:21:42 aspiers gibi: so I don't think it jumped the queue
11:22:00 gibi aspiers: true, so it can be that the check queue is owercrowded but the gate queue isny
11:22:03 gibi isnt
11:22:03 bauzas aspiers: gibi: I haven't paid attention to the status recently
11:22:13 aspiers gibi: yes exactly that is the case
11:22:25 bauzas aspiers: you know the difference between the gate and check pipelines, right?
11:22:26 aspiers I don't know why they are different resource pools

Earlier   Later