Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-24
14:46:48 kashyap efried: Hehe, noted
15:04:24 melwitt efried: ack
15:24:43 mriedem lyarwood: re getting the ceph job voting, we might consider disabling the ssh validation (which is on by default in tempest) to avoid spurious failures http://logs.openstack.org/06/641806/12/check/devstack-plugin-ceph-tempest/7fc39ec/testr_results.html.gz - ssh failing is something with networking breaking down, not really anything that should be a result of a ceph backend for storage
15:24:47 mriedem it'd also make the job fast
15:24:48 mriedem *faster
15:25:32 mriedem lyarwood: i also posted https://review.opendev.org/#/c/655452/ earlier today
15:30:20 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.opendev.org/555081
15:31:30 lyarwood mriedem: ack sounds and looks good, where's the best place to track devstack-plugin-ceph-tempest result trends btw?
15:31:57 mriedem here is a patch to disable the ssh validation https://review.opendev.org/655472
15:32:05 mriedem there is a graph that is out of date, sec
15:32:17 mriedem http://grafana.openstack.org/d/-iKINcImz/ceph-failure-rate?orgId=1
15:32:39 mriedem https://opendev.org/openstack/project-config/src/branch/master/grafana/ceph.yaml needs fixing to fix that graph
15:32:51 mriedem otherwise i think melwitt might be tracking ceph job failure rates somewhere
15:33:53 lyarwood kk, I can take a look at fixing the graph if there's not another way
15:34:24 melwitt I've been tracking via eyeball because I keep forgetting how to get the graph that shows the comparison with the tempest-full job
15:34:40 mriedem that's what that graph above is for, but it's broken
15:35:00 melwitt haha. I can also try to fix it
15:35:05 mriedem first it was broken by the ceph job renames, but now i think it's broken b/c of some zuulv3 thing, i had talked with corvus about it before but don't remember what needs fixing now
15:36:38 mriedem looking for one more core for this functional recreate test patch https://review.opendev.org/#/c/641521/
15:37:02 mriedem then i can claim victory on merging 4/47 patches of my cross-cell series while it was in runways for 2 weeks
15:42:02 stephenfin mriedem: I thought my cells-v1 series was big... I won't get to it tonight but I can look at that tomorrow morning
15:43:07 stephenfin (assuming no one gets to it before me)
15:43:59 mriedem thanks
15:44:00 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207
15:44:11 efried kashyap: I just did a thorough look at https://review.opendev.org/#/c/655193/
15:44:11 efried I would like to get some os-traits-y people (edleafe jaypipes) to scrutinize, esp. to make a ruling on whether/how we should do the split I suggested.
15:44:32 edleafe efried: buried in meetings etc until the afternoon
15:44:52 kashyap efried: /me looks; (while adding words to the other spec, so as to reduce your PTG scheduling workload :-))
15:45:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207
15:45:58 kashyap efried: Eagle eyes there! On "stibp"
15:46:00 efried kashyap: No hurry on my end
15:46:19 kashyap I missed to add it, due to all these subtle acronyms
15:47:13 efried kashyap: If it helps, I distilled that web page
15:47:13 efried 136 @node important_cpu_features_intel_x86
15:47:13 efried 148 @item @code{pcid}
15:47:13 efried 159 @item @code{spec-ctrl}
15:47:13 efried 171 @item @code{stibp}
15:47:14 efried 182 @item @code{ssbd}
15:47:14 efried 194 @item @code{pdpe1gb}
15:47:15 efried 248 @node important_cpu_features_amd_x86
15:47:15 efried 260 @item @code{ibpb}
15:47:16 efried 272 @item @code{stibp}
15:47:16 efried 283 @item @code{virt-ssbd}
15:47:17 efried 299 @item @code{amd-ssbd}
15:47:17 efried 313 @item @code{amd-no-ssb}
15:47:18 efried 325 @item @code{pdpe1gb}
15:47:35 kashyap efried: You actually read the source I lnked. It makes me happy that someone actually read it :D
15:48:35 kashyap Thanks for the handy posting here.
15:49:32 mgoddard mriedem: did you see my response re placement?
15:50:00 kashyap efried: Ah-ha, I missed 'stibp' because it was very recently added (21 March), and it isn't present in the HTML rendering
15:50:15 efried oh, interesting
15:50:19 kashyap [https://qemu.weilnetz.de/doc/qemu-doc.html#important_005fcpu_005ffeatures_005famd_005fx86]
15:50:20 jaypipes efried: what does "AMD x86 hosts" mean w.r.t. Spectre/Meltdown? I thought it was an Intel-only architectural problem that was being exploited?
15:50:32 mriedem mgoddard: i did now, thanks
15:50:46 efried jaypipes: I haven't a clue. kashyap --^
15:50:51 mgoddard mriedem: np
15:50:53 kashyap jaypipes: Not really; you fell for AMD's marketing :D
15:51:21 kashyap jaypipes: Meltdown is an Intel-only thing
15:51:30 kashyap jaypipes: Spectre affects both AMD _and_ Intel.
15:52:34 jaypipes kashyap: I didn't fall for anything... I was just asking a question :)
15:53:05 kashyap jaypipes: Yeah, sorry for the flippant answer. Hope I answered. But look at the qemu.weilnetz.de link I posted.
15:53:13 kashyap It shows all the CVEs that affect AMD hosts, too
15:53:21 jaypipes kashyap: so AMD's CPUs use the same speculative execution "algorithms"?
15:53:43 jaypipes ack, I'll read the paper.
15:53:52 jaypipes if I can get through it :)
15:54:05 kashyap jaypipes: Some yes, some not: https://www.amd.com/en/corporate/security-updates
15:54:52 melwitt jaypipes: sorry to interrupt... mnaser and I have a change to create request spec, build request, and instance mapping in a single database transaction https://review.opendev.org/586742 and could use your review eyeballs
15:56:38 jaypipes melwitt: pas de probleme. have a meeting for next 30 mins, will review after that
15:56:53 jaypipes melwitt: and no need to apologize! :)
15:57:36 melwitt merci beaucoup :)
15:58:38 jaypipes de rien
16:09:54 mnaser look at all this french
16:09:54 mnaser D:
16:10:16 mnaser (the nice type of French :p)
16:11:17 sean-k-mooney stephenfin: ill try to review the latest versoin of the cpu spec again
16:11:31 sean-k-mooney do you have any pending changes or is it fine teo start on v26
16:15:21 gibi efried: This morning I was about to start putting together the commits for the nova onboarding session. But then I found that you already created the DEMO commits (e.g. https://review.opendev.org/#/c/653504/) Is there something I can help with?
16:45:37 openstackgerrit Merged openstack/nova stable/pike: libvirt: set device address tag only if setting disk unit https://review.opendev.org/653514
16:52:56 mnaser reading scroll back, while it's nice to figure out those flags, I've noticed that different distros will tack in their own cpu flags.
16:53:11 mnaser which absolutely drives me f'n insane because it breaks live migration across qemus/operating systems.
16:59:39 aspiers efried_rollin: can your procedural -2 be removed from https://review.opendev.org/#/c/633855/ now that the spec is approved?
17:07:36 artom Who's good with Zuul? sean-k-mooney?
17:08:23 artom I'm trying to figure out why my "new" job (actually just nova-live-migration renamed) has apparently not run at all: https://review.opendev.org/#/c/653498/
17:08:39 artom There aren't even logs that I can look at :(
17:10:11 sean-k-mooney ill take a look
17:10:52 artom Appreciated :)
17:10:58 sean-k-mooney ah because you renamed it but did not add it to the check/gate queue
17:11:39 artom *facepalm*
17:11:41 artom Thank you!
17:11:49 sean-k-mooney comments in https://review.opendev.org/#/c/653498/4/.zuul.yaml
17:12:23 artom Yep, found those with a grep nova-live-migration :P
17:13:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498
17:13:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396
17:13:02 openstackgerrit Artom Lifshitz proposed openstack/nova master: Revert resize: wait for external events in compute manager https://review.opendev.org/644881
17:13:23 artom And now to pick up car from garage (and maybe lunch)
17:21:14 sean-k-mooney efried_rollin: regarding https://blueprints.launchpad.net/nova/+spec/libvirt-video-device-models it was marked as accpeted for train in last weeks meeting but the definiotn was not set to approved
17:22:17 sean-k-mooney efried_rollin: should it be updated or left at new? i was going to att the patch to the runway list so just checking before i do
17:49:34 mriedem https://review.opendev.org/#/c/649345/ should be good to go and fixes a stein regression
17:50:13 mriedem sean-k-mooney: done
17:50:51 sean-k-mooney thanks :)

Earlier   Later