| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 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 | |
| 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 :) | |
| 17:50:53 | mriedem | oh http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-04-18-14.00.log.html#l-197 | |
| 17:51:02 | mriedem | 14:41:14 <efried> If nobody has objections, I'll catch up with kashyap later and approve the bp if he's on board, cool? | |
| 17:51:17 | mriedem | i don't know if that happened | |
| 17:51:26 | sean-k-mooney | ah he had not syncted with kashap maybe | |
| 17:51:41 | sean-k-mooney | well there is no rush really | |
| 17:52:49 | sean-k-mooney | by the way for https://review.opendev.org/#/c/649345/ | |
| 17:53:40 | sean-k-mooney | i was going to point out that manages_network_binding_host_id might be a littel confuing in some cases | |
| 17:54:43 | sean-k-mooney | altully maybe not i was in the middel of finding out where we do the prot binding on swan for the livrt dirver | |
| 17:55:45 | sean-k-mooney | if we do it from the compute manager then thats all good | |
| 18:11:34 | jaypipes | melwitt, mnaser: still looking into that WSREP not prepared node thing... | |
| 18:18:41 | sean-k-mooney | WSREP is a galera thing right | |
| 18:24:00 | jaypipes | sean-k-mooney: yeah. though the actual error in this case is a red herring. any old internal error from any old RDBMS could cause this issue. | |
| 18:25:23 | melwitt | np :) | |
| 18:25:45 | sean-k-mooney | the only time i had had to deal with WSREP errors was when i ran out of diskspeack on one of my contolers | |
| 18:25:52 | sean-k-mooney | that was... fun to fix | |
| 18:26:10 | jaypipes | melwitt, mnaser: "The api_context_manager.writer decorators are not nestable." <-- I am almost positive that statement is incorrect. AFAIK, any methods that are decorated by transaction context manager will *enlist* the decorated function's DB calls into an existing transaction (and if there is no existing transaction, one will automatically be created the first time a SQL statement is called (via ORM or core expression API in sqlalchemy) | |
| 18:27:32 | melwitt | jaypipes: I thought the same thing so I tried that approach first, and in my func test I found that if the 2nd create() failed, the 1st create() remained in the sqlite database anyway | |
| 18:28:06 | jaypipes | melwitt: are they using the same RequestContext? | |
| 18:28:11 | melwitt | so I changed to the approach that's currently in the patch now | |
| 18:28:12 | melwitt | yes | |
| 18:28:21 | jaypipes | hmmm. | |
| 18:29:20 | jaypipes | melwitt: and both in the same thread of execution, yeah? | |
| 18:29:26 | jaypipes | melwitt: both create() calls, that is... | |
| 18:29:30 | melwitt | it's possible I did something wrong but I'm not sure how. I had originally decorated a function in compute/api with a writer decorator and just put all 3 create() calls in it | |
| 18:29:45 | melwitt | yeah | |
| 18:30:13 | jaypipes | melwitt: interesting. | |
| 18:30:27 | melwitt | the create() methods themselves are not decorated but they call decorated methods inside them. I dunno if that might be why | |
| 18:30:40 | jaypipes | melwitt: ftr, engineface's transaction context manager *should* only enlist into a single transaction (here is the relevant code, FWIW: https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py#L1050-L1052) | |
| 18:30:59 | jaypipes | melwitt: ok, lemme look further into this and see what might be causing this issue. | |
| 18:31:33 | jaypipes | melwitt: just wanted to make sure that all the calls were actually expected to be in the same RequestContext | |
| 18:31:42 | jaypipes | s/to be in the/using the/ | |
| 18:32:12 | melwitt | jaypipes: ok, thanks. I don't want to take up too much of your time on this | |
| 18:32:34 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648662 | |
| 18:32:59 | jaypipes | melwitt: not a worry, Melanie :) | |
| 18:33:05 | melwitt | jaypipes: it's a little complex in that the create() methods will use the object's internal self._context but all the objects self._context are set to the same RequestContext | |
| 18:33:41 | melwitt | but maybe that aspect can cause a break in the decorator nesting-ness? I'm not sure | |
| 18:34:49 | jaypipes | yeah, not entirely sure either :) will dig further. | |
| 18:56:02 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648662 | |