Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-24
14:37:44 efried I don't actually have a stake in what the answer is - I just want to see one :)
14:39:03 efried So it be like, "Before this wonderful feature, the instance might fail to come alive, but nova wouldn't know anything was wrong. Now we can fail the spawn operation, putting the instance in ERROR state, with a helpful log message indicating which bits are a problem."
14:44:12 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.opendev.org/555081
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 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:11 efried kashyap: I just did a thorough look at https://review.opendev.org/#/c/655193/
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 171 @item @code{stibp}
15:47:13 efried 159 @item @code{spec-ctrl}
15:47:13 efried 148 @item @code{pcid}
15:47:13 efried 136 @node important_cpu_features_intel_x86
15:47:13 efried kashyap: If it helps, I distilled that web page
15:47:14 efried 194 @item @code{pdpe1gb}
15:47:14 efried 182 @item @code{ssbd}
15:47:15 efried 260 @item @code{ibpb}
15:47:15 efried 248 @node important_cpu_features_amd_x86
15:47:16 efried 283 @item @code{virt-ssbd}
15:47:16 efried 272 @item @code{stibp}
15:47:17 efried 313 @item @code{amd-no-ssb}
15:47:17 efried 299 @item @code{amd-ssbd}
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 D:
16:09:54 mnaser look at all this french
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: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396
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: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

Earlier   Later