Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-06
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..
12:19:07 gibi bauzas: if you still have energy then this is the next patch in the bw series. I fixed up mriedem's comments https://review.opendev.org/#/c/680394
12:49:07 bauzas gibi: heh, sure, I'm now waiting for my train
12:49:43 gibi bauzas: meanwhile I found that I left some debug print statement in that patch :/ so I will need to go back and remove them.
12:50:04 bauzas gibi: oh, which one ? did I miss it too ?
12:50:15 bauzas if so, Starbucks, I hate you
12:50:18 gibi bauzas: in https://review.opendev.org/680394
12:50:24 gibi bauzas: not in the patch you approved
12:58:15 mriedem yonglihe: will you have time to address these comments in https://review.opendev.org/#/c/670790/ today or should someone else do those?
13:12:00 mriedem artom: let me know if you want to talk about any of my comments before you push changes
13:14:17 mdbooth mriedem dansmith: Looks like I've got another customer report affected by https://review.opendev.org/#/c/677736/
13:14:24 mdbooth Any chance we could merge that?
13:15:04 artom mriedem, ack - you saw I noticed a thing we all missed until now? The -1 on the massive patch
13:15:23 artom Not that hard a fix, but kind of a bitch to only spot it now
13:15:33 mriedem i haven't looked back on responses yet
13:16:11 artom mriedem, https://review.opendev.org/#/c/635229/58/nova/virt/libvirt/driver.py@7345 for when you're ready to look
13:16:31 mriedem yonglihe: also, as i said on that novaclient change, i'd like to see what it actually looks like in the output
13:16:48 mriedem if it's just a bunch of json blobs dumped to the console that's not very useful
13:18:03 mriedem artom: is that because i was asking about guest_cpu_tune and guest_numa_tune being exclusive?
13:18:14 openstackgerrit Dmitry Tantsur proposed openstack/nova master: Fix incorrect invocation of openstacksdk's baremetal.nodes() https://review.opendev.org/680684
13:18:17 dtantsur efried, dustinc, mriedem, another issue ^^^
13:18:30 dtantsur this one probably affects ironic CI as well
13:18:30 artom mriedem, yeah, that's what lead me down that path
13:18:35 mriedem \o/
13:18:42 artom mriedem, indeed :)

Earlier   Later