| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
collum joined #evergreen |
| 07:28 |
|
rjackson_isl_hom joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:36 |
|
mantis joined #evergreen |
| 09:04 |
|
Dyrcona joined #evergreen |
| 10:12 |
|
rfrasur joined #evergreen |
| 11:29 |
|
jvwoolf joined #evergreen |
| 11:59 |
|
Christineb joined #evergreen |
| 12:27 |
|
collum joined #evergreen |
| 13:08 |
|
Dyrcona joined #evergreen |
| 13:27 |
|
khuckins joined #evergreen |
| 13:39 |
csharp_ |
re: systemd, see bug 1912796 |
| 13:39 |
pinesol |
Launchpad bug 1912796 in OpenSRF "Docs: add systemd setup to README" [Wishlist,New] https://launchpad.net/bugs/1912796 |
| 13:40 |
csharp_ |
erg - I was thinking of websocketd - nevermind |
| 13:42 |
Dyrcona |
You could add a systemd init file for websocketd, though. That would be helpful. |
| 13:43 |
Dyrcona |
So, I'm looking into bug 1937294, and it looks like part of the problem is that all of concerto doesn't load. |
| 13:43 |
pinesol |
Launchpad bug 1937294 in Evergreen "Updating Evergreen for Newer PostgreSQL Versions" [Undecided,New] https://launchpad.net/bugs/1937294 - Assigned to Jason Stephenson (jstephenson) |
| 13:43 |
Dyrcona |
Copy numbers are different for one thing, but the db server didn't log any errors that looked relevant. |
| 13:45 |
JBoyer |
I have separate unit files for opensrf, sip, z3950, clark, and websocketd. Haven't been able to make myself genericize them and get them in a proper branch though. :( |
| 13:48 |
|
sandbergja joined #evergreen |
| 13:49 |
sandbergja |
Hi all -- I want to talk about releases and release notes. I'm doing so here (rather than #evergreen-release) so that it is logged. |
| 13:50 |
sandbergja |
Due to added pressures at work, I've stopped regularly checking #evergreen-release. It just hasn't seemed like a good use of my brain space to monitor it constantly just in case a release is planned, which only happens every month or two. |
| 13:50 |
sandbergja |
I am still happy to be pinged over email if release notes need to be compiled. |
| 13:51 |
sandbergja |
Or if we ever get back to planning releases via google calendar, I can use that to block off time to do point release notes |
| 13:53 |
sandbergja |
I think it would be good to re-evaluate how useful having the separate #evergreen-release channel is -- I've heard it described as a barrier to getting more help with releases |
| 13:53 |
sandbergja |
But that's a longer term discussion :-) |
| 13:54 |
sandbergja |
short term tl;dr: if you need some release notes from me, send me an email, as I am not monitoring #evergreen-release regularly :-) |
| 13:55 |
Dyrcona |
sandbergja: Fair enough. We're still using the Google sheet and releases are on Google calendar, though the dates are subject to change without notice. |
| 13:55 |
sandbergja |
also a huge thank you to abneiman for stepping in to do release notes for the past few releases -- they had tons of bug fixes, which makes it a really big lift |
| 13:55 |
sandbergja |
abneiman++ |
| 13:55 |
Dyrcona |
I think most of us have been busy lately. |
| 13:56 |
Dyrcona |
abneiman++ indeed |
| 13:56 |
sandbergja |
Dyrcona: true -- I forgot about the spreadsheet |
| 13:57 |
sandbergja |
but that becomes yet another place to check |
| 13:59 |
JBoyer |
sandbergja, I think a lot of the recent (since the hackaway at least) discussion has been about making release notes handling more automatic so we don't need to have someone sign up to explicitly take that task and handle it, with the hope that whoever may be putting that release together can just run ./build/tools/make_relnotes.sh or whatever as part of their process. |
| 13:59 |
JBoyer |
So hopefully there would need to be fewer people involved in putting a release together. |
| 14:00 |
JBoyer |
(I think; I couldn't really participate in the hackaway as much as I intended to) |
| 14:00 |
sandbergja |
I think that would be really helpful! |
| 14:01 |
sandbergja |
a lot of the problem boils down to: how do you coordinate 3-4 super-busy people |
| 14:01 |
sandbergja |
and even if it turns into 2-3 super-busy people to coordinate, it's still an improvement |
| 14:02 |
sandbergja |
(I also couldn't participate in the hackaway as much as I intended, so I'm just guessing based on what I heard) |
| 14:05 |
Dyrcona |
Well, our release process ought to be a lot simpler, so it doesn't require 3 or more people. |
| 14:10 |
sandbergja |
hear hear |
| 14:33 |
Dyrcona |
I'm seeing some weird stuff when loading concerto on Pg 11+. It looks like the parallel request workers could be changing IDs and possibly causing some updates not to happen. |
| 14:35 |
Dyrcona |
IDK, the more I look, the weirder things get. |
| 15:38 |
Dyrcona |
Maybe we should just switch to MariaDB. *ducks* |
| 15:42 |
rhamby |
bad Dyrcona! |
| 15:43 |
Dyrcona |
Well, PostgreSQL is breaking our data. |
| 15:43 |
Dyrcona |
I'm getting very different results when loading the sample data on Pg 11+. |
| 15:43 |
rhamby |
ug |
| 15:43 |
rhamby |
no bueno |
| 15:44 |
Dyrcona |
I'm trying to disable the parallel workers, but so far it's not working. |
| 15:44 |
rhamby |
actually my opinion on MariaDb is mostly positive though it lakes a few things that really irk me like inheritance |
| 15:44 |
rhamby |
s/lakes/lacks/ |
| 15:46 |
Dyrcona |
rhamby: Does inheritance irk you or does MariaDB's lack of inheritance irk you? |
| 15:47 |
rhamby |
Dyrcona the lack of it, I use it a lot for data work in postgres |
| 15:47 |
* Dyrcona |
hasn't actually used MariaDB. I've stuck mainly with MySQL despite it being acquired by the Evil Empire. |
| 15:48 |
jeff |
Dyrcona: can you share steps to reproduce the issue you're seeing, and the symptoms? I'm curious. |
| 15:48 |
Dyrcona |
OK. Thought I'd ask, because a lot of people don't like table inheritance. |
| 15:48 |
Dyrcona |
jeff: Just --load-all-sample on Pg11+ and watch the tests fail, particularly, live_t/20-hold-targeter.t |
| 15:49 |
Dyrcona |
I'm comparing between Pg10 and Pg11 side by side and they get different numbers of copies in different copy locations. |
| 15:50 |
Dyrcona |
I'm assuming parallel execution is the problem, but it could be something else. Unfortunately, there are no errors or other useful messages logged. |
| 15:50 |
rhamby |
just a straight up count(*) from asset.copy where location = foo; ? |
| 15:50 |
Dyrcona |
So far, trying to disable parallel execution in the SQL to load the data isn't working. |
| 15:50 |
Dyrcona |
Hang on. |
| 15:53 |
Dyrcona |
Since Evergreen paste is busted, I'll paste a one-liner here: |
| 15:53 |
Dyrcona |
select copy_location.id, copy_location.name, copy_location.holdable from asset.copy_location join asset.copy on copy.location = copy_location.id join asset.call_number on copy.call_number = call_number.id and call_number.record = 42 order by id; |
| 15:54 |
Dyrcona |
On Pg 11 you get 10 copies in non-holdable locations. On Pg 10, I get 7 copies in non-holdable copy locations. Also the location names are different. |
| 15:55 |
Dyrcona |
Also, if you do 'request open-ils.hold-targeter open-ils.hold-targeter.target {"hold":263}' in srfsh, you get different results. This is from the failing hold-targeter test and record 42 is the record in question. |
| 15:55 |
Dyrcona |
I should also mention that the copies and call numbers tend to get different ids in either Pg version. |
| 15:57 |
Dyrcona |
I'm going to bug the good people of #postgresql about disabling parallel workers while running a script. |
| 16:01 |
Dyrcona |
I'm also starting to think that the problem isn't parallel execution per se. |
| 16:17 |
jeff |
I suspect it's "test data load relies on assumptions about sequences that are no longer valid", but I haven't gotten hands-on with it yet. Might carve out time tonight. |
| 16:18 |
Dyrcona |
jeff: It's more than that. |
| 16:23 |
jeff |
ah, I see. |
| 16:29 |
Dyrcona |
That query I pasted gives very different results, so I think it is more than just assumptions about ids. Setting max_parallel_workers_per_gather to 0 doesn't help, so I'm starting to think the problem is something else. |
| 16:33 |
Dyrcona |
On the plus side, psql interactive mode in Emacs makes it easy to compare the results in Pg10 vs. Pg11. |
| 16:46 |
Dyrcona |
There is such a thing as being too clever. |
| 17:27 |
|
mmorgan left #evergreen |
| 17:28 |
abneiman |
belatedly mmorgan++ for also release-notes-ing for those two monster releases! & pursuant to what sandbergja said above, I'm always willing to help but don'tspend a lot of time in IRC (and windows doesn't like to give me Quassel notificaitons), so, alternate methods of flagging me down are always OK :) |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:43 |
|
Christineb joined #evergreen |
| 19:43 |
|
troy joined #evergreen |
| 19:51 |
|
troy joined #evergreen |
| 19:52 |
|
Christineb joined #evergreen |
| 20:01 |
|
ejk joined #evergreen |
| 20:11 |
|
eby joined #evergreen |
| 20:24 |
|
degraafk joined #evergreen |
| 20:24 |
|
jeffdavis joined #evergreen |
| 21:15 |
|
jvwoolf joined #evergreen |
