Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-06
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 sean-k-mooney then push to land the cpu series
11:05:38 aspiers +1 for that ;-)
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 user_id and project_id colume to Migration https://review.opendev.org/673990
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: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 bauzas aspiers: gibi: I haven't paid attention to the status recently
11:22:03 gibi isnt
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
11:22:35 aspiers bauzas: yes of course
11:22:55 gibi could be that patches sitting in the check queue consuming resouce but now moving forward?
11:23:34 bauzas oh, freaky
11:23:38 bauzas http://zuul.openstack.org/status
11:23:54 aspiers bauzas: yes this is what we are talking about :)
11:24:33 bauzas hard to see with a flakey connection :)
11:25:06 aspiers The gate looks fine, but not check
11:25:24 sean-k-mooney gibi: infra were seeing quota issue causing nodepool failures
11:25:38 sean-k-mooney as a result the queue built up a bit
11:25:45 gibi sean-k-mooney: thanks, so we need to be patient
11:25:46 sean-k-mooney i think they were fixed yesterday evening
11:25:52 sean-k-mooney yes
11:25:59 sean-k-mooney it will just take a while
11:26:11 aspiers yup
11:26:16 sean-k-mooney although if it does not wew might need a zuul restart to clear the queue
12:02:18 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Nova object changes for forbidden aggregates request filter https://review.opendev.org/671072
12:02:18 openstackgerrit Shilpa Devharakar proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata https://review.opendev.org/671074
12:02:19 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Add a new request filter to isolate aggregates https://review.opendev.org/671075
12:02:19 openstackgerrit Shilpa Devharakar proposed openstack/nova master: Docs for isolated aggregates request filter https://review.opendev.org/667952
12:04:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add min service level check for migrate with bandwidth https://review.opendev.org/680394
12:06:06 openstackgerrit Dongcan Ye proposed openstack/nova master: Get pci_devices from _list_devices https://review.opendev.org/680674
12:09:07 dtantsur efried, dustinc, update: the grenade failure in our CI probably is not caused by the instance_id problem..

Earlier   Later