| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-30 | |||
| 13:05:52 | zzzeek_ | guess we'd have to test it. blah | |
| 13:06:02 | jaypipes | :) | |
| 13:06:07 | zzzeek_ | how you do even test locking on MySQL :) it has such wierd behavior | |
| 13:06:26 | kashyap | zzzeek_: I think jaypipes just tries it on production users ;-) | |
| 13:06:37 | zzzeek_ | well, repeatable read. guess i can try a concurrent update against "a" selecvted alone, vs "a" selected in the subquery | |
| 13:06:56 | kashyap | But more seriously, /me is glad with all these *SQL experts, self can't do beyond 101 stuff | |
| 13:07:16 | zzzeek_ | can't beat a job that pays me to just sit around and know things | |
| 13:07:35 | jaypipes | zzzeek_: for the record, postgresql's select for update docs are virtually identical. | |
| 13:07:47 | zzzeek_ | jaypipes: yes, but w/ pg we dont get shenanigans like this | |
| 13:07:56 | jaypipes | zzzeek_: how do you know? :) | |
| 13:08:18 | zzzeek_ | jaypipes: its postgresql! it's a crystalline structure of timeless perfection! | |
| 13:08:43 | jaypipes | hehe | |
| 13:08:56 | zzzeek_ | when you find an ingenious feature of postgresql, and ask, "when was this developed?", the answer is: never. all PGs features exist outside of time-space | |
| 13:09:12 | jaypipes | lol :) | |
| 13:09:13 | zzzeek_ | like in "Interstellar" | |
| 13:09:52 | jaypipes | it does actually seem like PG has a similar behaviour with regards to indexing. | |
| 13:10:05 | zzzeek_ | jaypipes: meaning, you can't lock a row that doesnt refer to index columns? | |
| 13:10:30 | jaypipes | zzzeek_: "FOR UPDATE and FOR SHARE cannot be used in contexts where returned rows cannot be clearly identified with individual table rows;" | |
| 13:10:37 | jaypipes | zzzeek_: which makes sense, kinda. | |
| 13:10:58 | jaypipes | zzzeek_: if you can't identify a particular record with a condition, then you shouldn't be able to lock it. | |
| 13:11:01 | zzzeek_ | jaypipes: oh. that may be it then, is mysql making a virtual table out of the subquery? | |
| 13:11:27 | jaypipes | zzzeek_: could be? really would need to chat with this guy and find out what data is in the two tables | |
| 13:11:39 | jaypipes | zzzeek_: could be a weird edge case of some sort. | |
| 13:12:01 | zzzeek_ | jaypipes: https://bugs.mysql.com/bug.php?id=34182 | |
| 13:12:16 | zzzeek_ | jaypipes: oh this is falcon storage engine | |
| 13:12:21 | jaypipes | oh ffs | |
| 13:12:30 | zzzeek_ | jaypipes: that bug. let me ask user | |
| 13:15:04 | jaypipes | zzzeek_: note that that bug is describing a different behaviour. that bug is describing when the FOR UPDATE clause appears within the subquery. | |
| 13:15:26 | jaypipes | zzzeek_: and it's also 10 years old :) and the (now irrelevant) falcon storage engine | |
| 13:15:26 | zzzeek_ | jaypipes: ah | |
| 13:15:32 | zzzeek_ | jaypipes: yep | |
| 13:16:42 | jaypipes | zzzeek_: what's the bug link for SA? | |
| 13:17:50 | zzzeek_ | jaypipes: https://bitbucket.org/zzzeek/sqlalchemy/issues/4246/compound-query-select-apply-for-update-to | |
| 13:24:21 | jaypipes | zzzeek_: I wholeheartedly disagree with the Diggsey user in the original 4100 bug. | |
| 13:24:53 | zzzeek_ | jaypipes: :) so did I ! | |
| 13:25:37 | zzzeek_ | jaypipes: this is my life. non DB folks just complaining all day | |
| 13:26:04 | jaypipes | zzzeek_: heh. yeah, but you're used to it by now. | |
| 13:27:57 | openstack | Launchpad bug 1592015 in OpenStack Compute (nova) "libvirt: cleanup of a volume backed instance resize leaves behind the instance directory" [Medium,In progress] - Assigned to Feodor Tersin (ftersin) | |
| 13:27:57 | jmccarthy | Hi folks ! I believe I'm hitting this here .. but not at all sure where to go with it .. https://bugs.launchpad.net/nova/+bug/1592015 | |
| 13:28:12 | jmccarthy | Be nice ;) | |
| 13:29:49 | jmccarthy | In my case, after cold migration, a disk.info is left behind in old instance dir which doesn't get cleaned up (after verify resize) | |
| 13:30:14 | jaypipes | zzzeek_: aha! | |
| 13:30:35 | jaypipes | zzzeek_: I think I might have found a reason why Julien's particular query is doing what it's doing. | |
| 13:30:40 | zzzeek_ | jaypipes: oh yeah | |
| 13:35:02 | jaypipes | zzzeek_: added a comment on the bug above. | |
| 13:35:32 | mriedem | jmccarthy: if you want to take over https://review.openstack.org/#/c/414710/ i could restore it and you could rebase it | |
| 13:35:37 | mriedem | if it fixes the bug | |
| 13:35:47 | zzzeek_ | jaypipes: see that's some mysql guru shit right there | |
| 13:36:17 | mriedem | jmccarthy: although it looks like a series https://review.openstack.org/#/q/status:abandoned+topic:disk_snapshots | |
| 13:36:52 | jaypipes | zzzeek_: I believe postgresql will return an error when it sees an expression like that which it knows it cannot determine an effective join condition that can be applied in the read view protection. | |
| 13:37:10 | openstack | Launchpad bug 1666831 in OpenStack Compute (nova) ocata "Nova recreates instance directory after migration/resize" [Low,Fix committed] - Assigned to Lee Yarwood (lyarwood) | |
| 13:37:10 | mriedem | jmccarthy: comment 8 also says this was fixed with an alternative bug https://bugs.launchpad.net/nova/+bug/1666831 in ocata | |
| 13:37:15 | mriedem | jmccarthy: which release are you on? | |
| 13:37:45 | zzzeek_ | jaypipes: not sure about that. that's a standard SQLAlhcemy query | |
| 13:38:10 | jaypipes | zzzeek_: note that the way InnoDB works, the ORDER BY clause is required to generate the gap locks that would act as the read view protection for other transactions. | |
| 13:38:48 | zzzeek_ | jaypipes: ok....well if true this means we'd still need to change the query, but im doing some local testing and not sure if im replicating yet | |
| 13:39:01 | jaypipes | zzzeek_: we should change channel, though :) mriedem will surely be getting antsy :) | |
| 13:39:08 | zzzeek_ | jaypipes: sure. | |
| 13:41:37 | jmccarthy | mriedem: I'm using kolla images built off master | |
| 13:41:49 | zzzeek_ | jaypipes: the test script I'm running so far is confirming what he is seeing | |
| 13:42:44 | mriedem | jmccarthy: then that sounds like a regression and would be a new bug where you'd have to provide your details, and probably refer to that other bug for context | |
| 13:43:30 | jmccarthy | mriedem: Ok, I can look into raising a new bug, I'll check out that alternate - thanks ! | |
| 13:44:39 | jaypipes | zzzeek_: moved to #sqlalchemy | |
| 13:45:22 | jmccarthy | Ohh ok missed the # in comment 8 | |
| 13:51:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Implement granular policy rules for placement https://review.openstack.org/524425 | |
| 13:51:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup placement policy generator docs https://review.openstack.org/565225 | |
| 13:53:34 | kashyap | mriedem: Morning; when you can, want to put this through? -- https://review.openstack.org/#/c/565043/ (libvirt: Make `cpu_model_extra_flags` case-insensitive for real) | |
| 13:53:41 | jaypipes | mriedem: mornin. you ready for a proper review on ^^ or are you still WIP'ing? | |
| 13:53:42 | kashyap | (It needs to be backported all the way back to Ocata) | |
| 13:55:29 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:58:01 | mriedem | jaypipes: i need to split it up and add tests yet | |
| 14:04:29 | jaypipes | mriedem: k. so hold off? | |
| 14:05:28 | mriedem | jaypipes: yeah, unless you want to skim, it's mostly mechanical | |
| 14:06:10 | jaypipes | mriedem: ack | |
| 14:06:28 | bauzas | efried: jaypipes: hola | |
| 14:06:46 | efried | bauzas: yeaux | |
| 14:06:50 | openstack | Launchpad bug 1767076 in tripleo "Creating pingtest_sack fails: Failed to schedule instances: NoValidHost_Remote: No valid host was found" [High,Triaged] - Assigned to Quique Llorente (quiquell) | |
| 14:06:50 | bauzas | efried: jaypipes: looks like we have some transition problem for Pike https://bugs.launchpad.net/tripleo/+bug/1767076 | |
| 14:06:56 | bauzas | transitive* | |
| 14:07:10 | bauzas | efried: jaypipes: see https://logs.rdoproject.org/openstack-periodic-24hr/periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset002-pike-upload/7dadafb/overcloud-novacompute-0/var/log/nova/nova-compute.log.txt.gz#_2018-04-25_06_00_40_809 | |
| 14:07:23 | bauzas | efried: jaypipes: I wonder if that's related to https://review.openstack.org/#/c/524263/ | |
| 14:10:20 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: Handle PortNotFoundClient exception when getting ports https://review.openstack.org/565183 | |
| 14:11:55 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 14:15:20 | jaypipes | bauzas: looks like triple-o isn't upgrading placement first. | |
| 14:15:44 | bauzas | how do you know that ? | |
| 14:15:59 | bauzas | I mean, I understand you, I just want to know how to check that | |
| 14:18:41 | bauzas | jaypipes: mmm, when comparing pike and master, we make now the fact to not see correct aggregates and RPs a blocking stuff https://github.com/openstack/nova/commit/b214dfc41928d9e05199263301f8e5b23555c170 | |
| 14:18:54 | bauzas | owalsh: ^ | |
| 14:19:07 | bauzas | shit, I need to go find my daughters | |
| 14:20:08 | owalsh | bauzas, jaypipes: don't believe that's an upgrade job | |
| 14:21:21 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: ironic: Report resources as reserved when needed https://review.openstack.org/517921 | |
| 14:21:26 | jaypipes | bauzas: having trouble understanding you... I don't see what that patch has to do with a KeyError | |
| 14:22:21 | bauzas | jaypipes: nevermind https://review.openstack.org/#/c/524263/ | |
| 14:23:03 | jaypipes | owalsh, bauzas: the reportclient is bombing because it has been upgraded to expect the generation field in the return from placement API. but placement hasn't been upgraded first and so isn't returning the generation field. | |
| 14:23:26 | bauzas | anyway, /me needs to leave | |
| 14:23:43 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_BLOCK_LM_WITH_VOLUMES_VERSION https://review.openstack.org/563984 | |
| 14:23:44 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_NUMA_VERSION_PPC https://review.openstack.org/564010 | |
| 14:23:45 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop BAD_LIBVIRT_NUMA_VERSIONS https://review.openstack.org/564011 | |
| 14:23:46 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop BAD_LIBVIRT_CPU_POLICY_VERSIONS https://review.openstack.org/564012 | |
| 14:29:44 | kashyap | stephenfin: Since you asked, ^^^ if you want to queue them up. Two patches already have +2 from MattR; and just addrressed two minor things in the other two patches. | |