| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 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 | |
| 19:07:17 | melwitt | jaypipes: based on the code you linked, it really should work to nest it so I went back and tried it all again and it looks like it does indeed work properly. I must have messed something up last time, sorry for that :( being able to nest makes the code 1000x better so thank you for pointing it out. I'm going to respin | |
| 19:12:28 | melwitt | jaypipes++ | |
| 19:12:50 | tssurya | mriedem: following up on our discussion yesterday regarding filters/sorting I have a doubt here: https://review.opendev.org/#/c/648662/6/nova/api/openstack/compute/schemas/servers.py@544 could you leave a comment when you get time ? | |
| 19:21:33 | dansmith | tssurya: see if I answered your question | |
| 19:21:48 | melwitt | turns out what I did wrong was not pass the RequestContext to the decorated outer method. it needs to be passed in for the decorator to start the transaction and then that will get used by the subsequent create() methods | |
| 19:22:14 | tssurya | dansmith: thanks looking | |
| 19:23:15 | tssurya | dansmith: ah you mean do something like 'sort_key': multi_params(VALID_SORT_KEYS_V273) ?, | |
| 19:23:23 | dansmith | tssurya: yeah | |
| 19:23:29 | tssurya | got it, I'll try to update that patch :) thanks! | |
| 19:25:40 | openstackgerrit | melanie witt proposed openstack/nova master: Create request spec, build request and mappings in one transaction https://review.opendev.org/586742 | |
| 19:36:34 | jaypipes | melwitt: no worries, Melanie! :) | |
| 19:40:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Add image type capability flags and trait conversions https://review.opendev.org/652710 | |
| 19:40:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Make libvirt expose supported image types https://review.opendev.org/653454 | |
| 19:40:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | |
| 19:42:01 | JamesBenson | hey all | |
| 19:42:04 | JamesBenson | I'm getting a nova_compute issue with this error: https://paste.fedoraproject.org/paste/EZYsQ8eDlp9gDjA8BB1YiA/ | |
| 19:42:12 | JamesBenson | This is with a xen hypervisor | |
| 19:42:38 | JamesBenson | I'm installed os_xenapi with pip | |
| 19:46:27 | dansmith | oh so you're the one! | |
| 19:51:59 | JamesBenson | dansmith??? | |
| 19:52:09 | dansmith | JamesBenson: ...guy still using xen :) | |
| 19:52:43 | JamesBenson | dansmith, trust me, this is the first time and only because we are getting software that is based off of the xen hypervisor. | |