| Time |
Nick |
Message |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:32 |
|
abowling1 joined #evergreen |
| 06:39 |
|
Stompro joined #evergreen |
| 07:08 |
|
Callender joined #evergreen |
| 07:08 |
|
Callender_ joined #evergreen |
| 07:27 |
|
agoben joined #evergreen |
| 07:48 |
|
Callender joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:50 |
JBoyer |
Right-o, since restarting memcache servers mid day is Not Cool, can anyone help me pin down where some stale data is lurking? Some aou emails and hours were updated this morning and they simply will not appear in the TPAC. |
| 08:51 |
JBoyer |
Since there were so few, I used memcrm to remove all TPAC_aou(_address|hoo).* keys and that didn't do it. The hours changes appear, but not the email. |
| 08:53 |
dbs |
Possibly cached in the apache processes themselves |
| 08:54 |
JBoyer |
Ugh. That or the TT2 cache I suppose. |
| 08:55 |
JBoyer |
A quick cycling restart should prove that out in a few minutes. |
| 08:55 |
JBoyer |
(By the time I figure this out it will have been pushed out of memory "naturally" and I'll never know what did it. :/ ) |
| 08:58 |
tsbere |
JBoyer: When we make changes to that info I tend to issue apache2 reloads across all apache servers. I don't usually touch memcache. |
| 08:59 |
JBoyer |
I thought starting there would be minimally obnoxious (and it is; literally no one noticed, including apache!) but that's probably how I'll handle it from here on. |
| 09:00 |
tsbere |
JBoyer: reload is much less obvious than restart with apache :D |
| 09:08 |
csharp |
so is there a plan to release a 2.11.2 before mid-January? Just trying to plan on whether to do 2.11.1 + backports or wait for 2.11.2 for our target release for MLK weekend upgrade |
| 09:08 |
* csharp |
really looks forward to dumping the staff client :-/ |
| 09:11 |
|
kmlussier joined #evergreen |
| 09:11 |
* JBoyer |
commiserates with csharp. Looking forward to stealthy thief-in-the-night upgrades every quarter or so instead of annual blowouts. |
| 09:11 |
csharp |
exactly |
| 09:13 |
|
bos20k joined #evergreen |
| 09:15 |
kmlussier |
csharp: There's a maintenance release on the calendar for next Wednesday. |
| 09:15 |
kmlussier |
If it happens, I guess I'll have to work on point release notes on Tuesday since I'm taking Wednesday off. |
| 09:17 |
* kmlussier |
thinks it's worth doing for the closed dates editor fix alone. |
| 09:20 |
|
yboston joined #evergreen |
| 09:22 |
JBoyer |
dbs++ |
| 09:22 |
JBoyer |
tsbere++ |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:34 |
|
slink_ joined #evergreen |
| 09:37 |
|
maryj_ joined #evergreen |
| 09:37 |
|
maryj joined #evergreen |
| 09:42 |
|
maryj joined #evergreen |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:09 |
|
littleDude joined #evergreen |
| 10:12 |
bos20k |
Hello. Question regarding Postgres load balancing - pgpool-II or Bucardo? Something else? Or am I asking for trouble by trying to load balance? |
| 10:13 |
Dyrcona |
bos20k: You could also ask in the #postgresql channel. I'm sure you can start a flame war there. :) |
| 10:14 |
Dyrcona |
I have no experience with either, so I cannot offer any useful advice. |
| 10:14 |
JBoyer |
First I'd want to know how many titles/items and ous are in your system. You might get more benefit out of PG tuning than load balancing. |
| 10:16 |
berick |
bos20k: you're not asking for trouble. load balancing PG is fairly common, I think. But what JBoyer said.. be sure it's worth it. |
| 10:16 |
bos20k |
JBoyer: Well, we aren't really having a performance problem. What we need is replication so nothing is lost if the main server goes down. Load balancing and automatic failover would be a nice plus. |
| 10:16 |
Dyrcona |
Ah, replication you're after.....That, I know a tiny bit about. :) |
| 10:17 |
bos20k |
I just know Evergreen does some complex stuff with Postgres so I want to make sure there aren't any gotchas or whatever to look out for. |
| 10:18 |
JBoyer |
Most OpenSRF methods that require write access (i.e. the master db) specify that so at some layer it can be handled the right way. It looks like there's some support built into Evergreen for multiple DBs but I've never seen it used. I would hope that one of the PG specific options would just do the right thing re: routing writes. |
| 10:19 |
JBoyer |
Failover and such I'm not as familiar with, but I think at one point someone was using pg-pool II, the only thing I've used from Bucardo is their pg check script. |
| 10:20 |
berick |
we're using pgpool-II |
| 10:20 |
bos20k |
berick: are you using it for load balancing in a replicated setup? Anything to watch out for re evergreen vs pgpool? |
| 10:22 |
Dyrcona |
I'm trying to figure out what we're using, but not having much luck. :) |
| 10:23 |
berick |
bos20k: yep, load balancing in a replicated setup. I didn't set it up, though, so I don't know all the details. I do know that others have used pgpool as well, though, and EG is smart enough to put all writes into a transaction, forcing write calls to the master DB. |
| 10:24 |
bos20k |
berick: Hmmm, so the writes would be forced to one server as far as you know? |
| 10:24 |
Dyrcona |
We have replication with failover, but not sure if the failover is automatic. It was setup before I got here. |
| 10:25 |
berick |
bos20k: yes |
| 10:25 |
berick |
bos20k: a reference to PINES using pgpool as well... https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_faq_2 |
| 10:26 |
bos20k |
berick: ok, thanks, yes, I will have to decide if it is worth it to go through all that trouble of messing with pgpool-II or just set up some simple replication... |
| 10:29 |
berick |
bos20k: yeah.. replication is a must, but load balancing is only worth it if you really need it, IMO. it has its own overhead/complexity, and I can't say I've ever been in a situation where "automatic failover" was automatic. it's never been that simple. |
| 10:29 |
berick |
but i'm not a DBA -- it's just my experience |
| 10:29 |
JBoyer |
bos20k, You should absolutely use PG's built in replication if you're able, I wouldn't trust a front end like pgpool to do replication. If it offers that feature it's because it's older than PG's built in support. (Also, multi-master replication where multiple machines can accept writes is not common at all.) |
| 10:29 |
Dyrcona |
We're using the built-in replication, I'm pretty sure. |
| 10:30 |
JBoyer |
Dyrcona, It's so nice. I loved it so much, but our third replicant just couldn't keep up. so we're back to slony for now. Maybe 9.4-5? :( |
| 10:31 |
Dyrcona |
We're only replicating to 1 other db server. |
| 10:32 |
JBoyer |
Our third machine is across a slower crosslink in another DC and it's much older hardware. It wouldn't be an issue otherwise. :/ |
| 10:33 |
JBoyer |
I should probably do something different for that machine anyway. I'm not even sure we could run EI off of it anymore, it's literally just a hot backup in case the other DC is removed from the map. |
| 10:34 |
bos20k |
Thanks all for the input! |
| 10:36 |
|
jvwoolf joined #evergreen |
| 10:43 |
|
Christineb joined #evergreen |
| 10:57 |
|
rjackson_isl joined #evergreen |
| 11:05 |
|
bmills joined #evergreen |
| 11:40 |
|
Dyrcona joined #evergreen |
| 11:56 |
|
krvmga joined #evergreen |
| 12:13 |
|
mmorgan joined #evergreen |
| 12:13 |
|
brahmina joined #evergreen |
| 12:13 |
* jeff |
muses once more about prompting staff when updating a phone number to confirm or update other phone numbers on the account (such as default hold pickup phone number) |
| 12:17 |
* Dyrcona |
recalls that staff sometimes think changing a phone number updates all of the patron's options, etc., including the number on outstanding holds. |
| 12:20 |
* kmlussier |
likes the idea of such a prompt |
| 12:22 |
jeff |
well, on the subject of "number on outstanding holds", i still like the idea of not having per-hold phone numbers, but there's still the issue of the opac.default_phone user setting and friends. |
| 12:22 |
Dyrcona |
Most people like the idea of a prompt until they have to click a button a few thousand times. |
| 12:22 |
jeff |
well, the idea of course would be to not show it if it wasn't needed... :-) |
| 12:23 |
Dyrcona |
Well, that goes without saying.... :) |
| 12:24 |
jeff |
currently there isn't an easy way that i'm aware of for staff to find a phone number on an account if it's in that user setting or in a hold. |
| 12:24 |
|
jason___ joined #evergreen |
| 12:25 |
Dyrcona |
jeff: I don't think they can, never mind it being easy. |
| 12:25 |
jeff |
use case: local business called to report that their new phone number was getting hold pickup notifications from us, and staff were unable to find any account with that number on file, because the number wasn't present in anyone's actor.usr.*_phone column. |
| 12:26 |
mmorgan |
It is findable, easy, not so much. |
| 12:26 |
jeff |
we don't get a lot of these (this is perhaps the second i can remember since 2008), but it touches on a general area of potential improvement anyway. |
| 12:27 |
* mmorgan |
would also like to see such a prompt. |
| 12:27 |
jason___ |
I'm back with another first time setup question: When setting up the postgres database for a new installation of Evergreen, can I use any strings I want for the <admin-user> and <admin-pass> and <dbname> as long as I use them consistently? |
| 12:28 |
Dyrcona |
jason___: Yes, but I recommend using the same name as your db user for the database name, unless you're using potgres as the user name. |
| 12:29 |
Dyrcona |
jason___: You'll want to remember admin-user and admin-pass. That will be your Evergreen administrator account, i.e. the Evergreen user who can do eveything. |
| 12:30 |
jason___ |
Got it, meaning the user that the guide recommends be called "evergreen"? |
| 12:30 |
jason___ |
Understood |
| 12:30 |
Dyrcona |
jason___: When you connect to postgress without specifying a databse, it defaults to connecting to a database with the same name as the user that is connecting. |
| 12:31 |
Dyrcona |
So, naming the postgres user evergreen and the database evergreen makes it slightly easier to use psql and other tools on the database later. |
| 12:31 |
jason___ |
Got it, thanks very much for your help! |
| 12:31 |
kmlussier |
I don't think users mind seeing a prompt if the information is useful. The challenge is striking the balance between what information really needs to be conveyed in a prompt and what things the system should just handle on its own without bothering staff with a prompt. I think updating the holds phone number falls into the former category, especially since it's something that staff won't be seeing hundreds of times a day. |
| 12:31 |
|
brahmina joined #evergreen |
| 12:32 |
* Dyrcona |
can't type today. |
| 12:39 |
* Dyrcona |
kind of agrees with jeff that we don't need per-hold phone numbers. |
| 12:39 |
Dyrcona |
That's often a point of confusion. |
| 12:45 |
|
rlefaive joined #evergreen |
| 12:49 |
kmlussier |
Yeah, I don't know if some users find the per-hold option useful. Maybe they do, maybe the don't. It would be nice to find out if some people do have a reason for using different numbers for different holds. |
| 12:51 |
* mmorgan |
wonders if it would be less confusing and equally functional if per hold options were all yes/no |
| 12:51 |
mmorgan |
and picked up the current user preference for phone and sms. |
| 12:52 |
jeff |
we've gone further and just said "one set of prefs for all holds" |
| 12:52 |
jeff |
"pref in effect at time of hold becoming available on-shelf is what is used" |
| 12:57 |
jeff |
stated another way, notification prefs are per-user, not per-hold. |
| 12:58 |
mmorgan |
jeff: gotcha. I'm not sure I'd like to see per hold notification go away entirely in our situation. |
| 12:59 |
jeff |
Do you use it, or know how patrons use it? |
| 13:00 |
Dyrcona |
I could see maybe choosing TXT notification for something that is very important to you, and email or phone for less important things. |
| 13:00 |
Dyrcona |
I'm less sure why you'd want a different phone number for different holds. |
| 13:01 |
jeff |
I can't see not wanting to know via your preferred method(s) that your items are available. |
| 13:02 |
jeff |
Which is why I'm asking. :-) |
| 13:02 |
mmorgan |
I have definitely seen different notification settings per hold for the same patron. Can't speak to the patron's intent. |
| 13:06 |
kmlussier |
Preferred notification is your landline used by multiple people and material on hold is on a very sensitive topic? |
| 13:06 |
* kmlussier |
is just guessing. |
| 13:07 |
Dyrcona |
Landline....How quaint. :P |
| 13:07 |
jeff |
Our automated calls don't include item-level information. |
| 13:07 |
jeff |
But perhaps others do, sure. |
| 13:07 |
kmlussier |
Yeah, I would like to think most libraries don't include that information, but the patron might not realize that. |
| 13:07 |
Dyrcona |
The places where I've worked don't do automated calls. |
| 13:08 |
* mmorgan |
can think that a patron may want sms notification of a hold they're particularly interested in, but other holds can just go to email. |
| 13:09 |
* Dyrcona |
said that, too. That's the main reason that I could think of. |
| 13:10 |
mmorgan |
Dyrcona: So you did! :) |
| 13:10 |
Dyrcona |
:) |
| 13:11 |
Dyrcona |
Trouble is, you have to have good reasons to remove a feature, better reasons than putting it there in the first place. |
| 13:12 |
Dyrcona |
Although, rules don't apply if you're Google or the Gnome team. ;) |
| 13:12 |
* Dyrcona |
is eyeballing you Gnome Calc "maintainers." |
| 13:12 |
jeff |
confusing to users, confusing to staff, results in patrons not receiving expected notifications... do i need better reasons, or to justify the claims in my currently stated reasons? ;-) |
| 13:13 |
Dyrcona |
Well, you're going to have those users who do understand it, who use it, and who will be confused and surprised when it no longer works that way. |
| 13:13 |
* jeff |
nods |
| 13:13 |
* Dyrcona |
is still eyeballing the Gnome Calc team..... :P |
| 13:14 |
Dyrcona |
With every release of Gnome, Calc gets less and less useful. They may as well just ship a lollipop and be done with it. :) |
| 13:15 |
Dyrcona |
You don't want users saying that about Evergreen.... :) |
| 13:15 |
Dyrcona |
At least, I don't. |
| 13:15 |
Dyrcona |
But that's just one person's opinion. |
| 13:15 |
* jeff |
orders Dyrcona a box of lollipops off of Amazon |
| 13:15 |
Dyrcona |
:) |
| 13:15 |
* jeff |
receives the shipping notification via text message, because that's what he's configured for his account |
| 13:16 |
Dyrcona |
I thought of getting them and taking them to meetings to give out to anyone who says, "I want it to be simple." |
| 13:16 |
mmorgan |
Some users might appreciate hold notification via lollipop. ;-) |
| 13:17 |
* Dyrcona |
makes a Lp bug for hold notifications via lollipop and starts coding the branch.... |
| 13:17 |
|
jason___ joined #evergreen |
| 13:17 |
Dyrcona |
I get what jeff is saying and at the outset I said I mostly agreed. |
| 13:17 |
* jeff |
writes a nasty letter to Amazon support about there being no way to specify a different text number per order, and demands to know why Amazon doesn't ask him to pick his "Carrier" from a list of company names that does not actually include the company he pays for phone service. |
| 13:17 |
Dyrcona |
I can see a use for saying, I want a TXT for this because "muh disseration!" |
| 13:17 |
* jeff |
stops being silly |
| 13:18 |
* Dyrcona |
still can't type today.... |
| 13:18 |
Dyrcona |
I was doing so well, too.... ;) |
| 13:18 |
Dyrcona |
Anyway, all it takes is a couple of signoffs and there you go. ;) |
| 13:20 |
jeff |
Yeah. I'm arguing one extreme, but trying to give thought to other options as well. |
| 13:22 |
jason___ |
postgresql on ubuntu-trusty question: I installed postgresql with apt-get install postgresql but I'm at the point where I'm creating the Evergreen database and it's throwing errors that seem to indicate missing sub packages. Is there a list of required packages? Or a better way to install postgresql for Evergreen? |
| 13:23 |
bshum |
jason___: In the README, there's a make target that you can use to install all the postgresql server packages and other pre-req's |
| 13:24 |
bshum |
jason___: See like https://evergreen-ils.org/documentation/install/README_2_11.html#_setting_up_the_postgresql_server |
| 13:24 |
jason___ |
Sorry I missed that, thanks for your help |
| 13:28 |
jason___ |
That worked, thanks again! |
| 13:28 |
bshum |
Huzzah, coming along nicely :) |
| 13:57 |
|
collum joined #evergreen |
| 14:26 |
|
krvmga joined #evergreen |
| 14:47 |
Dyrcona |
I was just poking at our Z39.50 configuration to answer some questions, and I wondered if anyone has set up databases in the oils_z3950.xml for branches/systems. |
| 14:47 |
Dyrcona |
We just have one database that searches all of C/W MARS. |
| 15:02 |
bshum |
Dyrcona: I did, once upon a time setup various databases with different search scopes |
| 15:03 |
Dyrcona |
I was just thinking about it, because we have a member who is going to use Ingram iMatch, and I thought it would be a good idea to configure a "database" that only returns their holdings. |
| 15:03 |
Dyrcona |
I am assuming that it worked. :) |
| 15:08 |
Dyrcona |
It must work, right? The default includes an entry for BR1. :) |
| 15:09 |
|
maryj joined #evergreen |
| 15:28 |
jason___ |
I just ran all the "Starting Evergreen" stuff and got it to work, "testing connections" failed the first time, but worked after a reboot. Two questions: Do I need to manually start Evergreen after every boot with the default configuration? And can I now connect with a client app? |
| 15:33 |
|
kmlussier joined #evergreen |
| 15:44 |
dbs |
Dyrcona: yup we have all kinds of Z39.50 targets in oils_z3950.xml, supporting the search of various individual branches and systems |
| 15:45 |
Dyrcona |
dbs: Thanks! I was pretty sure it would work. |
| 15:45 |
bmills |
Dyrcona: we ended doing that for one library here for iMatch. just adding "/shortname_code/holdings" to the end of the new database entry's <zurl> and restarting simple2zoom brought it in pretty smoothly. you might not need the "holdings" bit depending on your needs, but we did for the library that was using iMatch |
| 15:46 |
Dyrcona |
jason___: Yes, you need to manually restart Evergreen. I try to run osrf_control --stop-all before shutting down, too. |
| 15:46 |
Dyrcona |
Someone was working on some init scripts, but I don't know how that turned out. |
| 15:46 |
JBoyer |
Dyrcona, if you already have a db that reports holdings that's all they need for iMatch. We had someone here set that up and they just needed to know what to tell Ingram about our 852s. |
| 15:47 |
Dyrcona |
bmills: That's what I thought, thanks! |
| 15:48 |
Dyrcona |
JBoyer: Yeah. I was thinking it might improve the experience if they had their own database. |
| 15:48 |
JBoyer |
A perfectly valid reason to look into it, yeah. |
| 15:50 |
Dyrcona |
Besides, I haven't actually done it since writing the example configuration. :) |
| 15:54 |
JBoyer |
Practice is good, right up until 30-40 libraries all have their own reasons for having a holdings db. ;) |
| 15:55 |
Dyrcona |
JBoyer: Or, 140 or so? :) |
| 15:57 |
JBoyer |
Sounds super worst case, yes. |
| 15:59 |
jason___ |
Dyrcona Got it, thank you |
| 16:00 |
|
bmills left #evergreen |
| 16:14 |
|
bmills joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
* kmlussier |
hits send on e-mail, cheers up because she can now get to community work she's been wanting to do, and then realizes that it's 5 p.m. and the working day has ended. |
| 17:08 |
mmorgan |
kmlussier: At least you got that email sent! |
| 17:08 |
berick |
the sun'll come up.. tomorrow |
| 17:09 |
kmlussier |
mmorgan: Yes, it means I must have accomplished at least one thing today. |
| 17:09 |
mmorgan |
:) |
| 17:09 |
|
jvwoolf left #evergreen |
| 17:10 |
kmlussier |
My kids think my entire job is writing e-mails. There are days when I have a hard time disputing that belief. |
| 17:11 |
mmorgan |
True. Good night! |
| 17:11 |
|
mmorgan left #evergreen |
| 17:27 |
|
jason___ left #evergreen |
| 18:00 |
|
bmills joined #evergreen |
| 18:08 |
|
brahmina joined #evergreen |
| 19:00 |
pinesol_green |
[evergreen|Dan Pearl] LP#1586509 Bug fix to LP#1352542 caused extraneous blank line to appear in - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fdeffc5> |
| 21:12 |
|
littleDude left #evergreen |
| 23:53 |
|
StomproJ joined #evergreen |
