| Time |
Nick |
Message |
| 01:20 |
|
dcook joined #evergreen |
| 04:36 |
|
[1]cfarley joined #evergreen |
| 05:21 |
|
gsams joined #evergreen |
| 07:21 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 08:04 |
|
JBoyer joined #evergreen |
| 08:05 |
|
kmlussier joined #evergreen |
| 08:13 |
|
rlefaive joined #evergreen |
| 08:15 |
|
kmlussier joined #evergreen |
| 08:18 |
jeff |
apparently it takes me about an hour to write a script to scrape property tax parcel information from the neighboring county |
| 08:20 |
rhamby |
jeff: depending on the government entity it might be lot faster to just run a random number generator :) |
| 08:30 |
|
ethomsen joined #evergreen |
| 08:31 |
jeff |
S WEST BAY SHORE DR |
| 08:31 |
jeff |
W BAY SHORE DR |
| 08:31 |
jeff |
S WEST BAYSHORE DR |
| 08:31 |
jeff |
SW BAYSHORE DR |
| 08:33 |
|
mrpeters joined #evergreen |
| 08:34 |
jeff |
even normalizing case and removing periods we have almost 100 ways of spelling this road. |
| 08:40 |
jeff |
property list uses only two spellings: |
| 08:40 |
jeff |
S WEST-BAY SHORE DR |
| 08:40 |
jeff |
S WEST-BAY SHORE DR DR |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:41 |
jeff |
and of course the USPS normalization is something else entirely: |
| 08:41 |
jeff |
SW BAY SHOR DR |
| 08:44 |
jeff |
no idea where that SHOR comes from. |
| 08:46 |
jeff |
google maps goes from "North West Bay Shore Drive" to "SW Bay Shore Dr" to "S W Bay Shore Dr" to "South Bay Shore Drive" |
| 08:51 |
jeff |
there is also an entry for WEST-BAY SORE DR, but thankfully no properties listed under it. |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:54 |
|
mdriscoll joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 08:59 |
miker |
yo dog, I heard you like SW BAYSHORE DR so I put a S WEST-BAY SHORE DR in your SW BAY SHOR DR |
| 09:04 |
|
maryj joined #evergreen |
| 09:18 |
|
bos20k joined #evergreen |
| 09:18 |
* Dyrcona |
wrestles with Apache configuration. |
| 09:22 |
|
yboston joined #evergreen |
| 09:22 |
|
mmorgan1 joined #evergreen |
| 09:29 |
|
abowling joined #evergreen |
| 09:30 |
|
terran joined #evergreen |
| 09:34 |
jeff |
so far, my favorite invalid city name is: LIMIT TO AVAILABLE ITEMS SORRY, NO ENTRIES WERE FOUND FOR "GRONMON" KEYWORD SEARCH TIPS TRY CHANG |
| 09:36 |
Dyrcona |
Well, that's.....special. |
| 09:39 |
Dyrcona |
Know what else is special? |
| 09:39 |
Dyrcona |
The load tends to go up on our public OPAC vm as the number of |
| 09:39 |
Dyrcona |
Apache drones goes down. |
| 09:39 |
* Dyrcona |
fat fingered the Enter key. |
| 09:40 |
Dyrcona |
At least while the number is dropping. |
| 09:43 |
jeff |
we have over 100 ways of spelling "Traverse City" |
| 09:43 |
jeff |
i think that number might be slightly up from last time i looked. |
| 09:43 |
jeff |
(oh, and that's after UPPER and BTRIM) |
| 09:44 |
Dyrcona |
:) |
| 09:44 |
jeff |
Dyrcona: are there a lot of apache children starting up, even though the total number of children is going down? |
| 09:44 |
Dyrcona |
IIRC, "Transverse City" was the title of a Warren Zevon album. |
| 09:45 |
jeff |
Dyrcona: i don't know how intensive a child shutting down is... |
| 09:45 |
Dyrcona |
jeff: I think there's too much churn through child processes on this box, yes. |
| 09:46 |
Dyrcona |
I'm going to experiment with minspareservers, maxspareservers, and removing the maxrequestworkers settings. |
| 09:46 |
Dyrcona |
Basically, set them all higher....with maxrequestworkers going to the default of 256. |
| 09:47 |
Dyrcona |
If that doesn't fix it, I'll up the maxconnectionsperchild setting. We have set rather low at 1,000. |
| 09:48 |
Dyrcona |
As a result of splitting the public and staff Apaches and services over two "bricks" is that I've noticed the staff side apaches end up using more RAM with the same maxconnectionsperchild. |
| 09:48 |
Dyrcona |
So, if anyone wants to look for memory leaks, I'd suggest starting with the gateway. |
| 09:51 |
Dyrcona |
The performance on the staff brick is much more smooth, but that's because there is a largely fixed number of clients. |
| 09:51 |
Dyrcona |
It varies a lot less from minute to minute than does the public side. |
| 09:54 |
dbs |
Dyrcona: OpenSRF gateway vs OpenSRF HTTP translator vs OpenSRF WebSockets gateway? |
| 09:55 |
Dyrcona |
Hmm... I'm starting to think that I should just change MaxConnectionsPerChild and see how that "helps." |
| 09:55 |
Dyrcona |
dbs: OpenSRF gateway. |
| 09:56 |
Dyrcona |
There has been talk of possible memory leaks in the web code, but I suspect it is on the staff side, based on what I see. |
| 09:56 |
* dbs |
not sure calling the OpenSRF WebSocket thingy a "gateway" was a good idea given the long-standing and very different OpenSRF gateway: http://evergreen-ils.org/documentation/release/OpenSRF/RELEASE_NOTES_2_4_x.html#_new_features_in_2_4_0 |
| 09:57 |
Dyrcona |
Yep. |
| 09:57 |
Dyrcona |
And the OpenSRF gatway was depreacated in favor the HTTP translator was deprecated in favor of the OpenSRF gateway. :) |
| 09:57 |
Dyrcona |
Or something..... ;) |
| 09:58 |
dbs |
Dyrcona++ |
| 09:58 |
* dbs |
disappears in a puff of smartass smoke |
| 09:58 |
Dyrcona |
:) |
| 10:00 |
jeff |
and don't forget /gateway ;-) |
| 10:00 |
Dyrcona |
Vroom! |
| 10:02 |
* Dyrcona |
almost feels like setting things back to defaults and letting Apache sort it out. |
| 10:05 |
|
mmorgan joined #evergreen |
| 10:07 |
Dyrcona |
JBoyer: I can see why you're interested in using mpm_event. |
| 10:10 |
jeff |
oh, USPS was normalizing oddly: |
| 10:11 |
jeff |
"S WEST-BAY SHORE DR DR" to "SW BAY SHOR DR" |
| 10:11 |
JBoyer |
I think that was Bmagic yesterday, but hey, if it helps. |
| 10:11 |
jeff |
"S WEST-BAY SHORE DR" to "S WEST BAY SHORE DR" |
| 10:11 |
jeff |
so, the silly doubled DR DR appears to confuse the heck out of it. |
| 10:11 |
Bmagic |
Dyrcona: yeah! Good timing, we were just working through a maxclients issue |
| 10:12 |
Bmagic |
turned out to be keepalivetimout setting. needed to be 1 and not 5 |
| 10:12 |
jeff |
remember folks, always pre-normalize before you normalize! :-P |
| 10:12 |
Bmagic |
however, I still think we need to raise the maxclients up from 150 to something higher, The VM's have plenty of resources |
| 10:12 |
Bmagic |
berick++ |
| 10:13 |
Dyrcona |
Bmagic: Yeah, we were at 120 and then 150. I think my issue is process churn. |
| 10:14 |
JBoyer |
When I raised max clients too high RAM use would ramp up forever until something implodes. (with nowhere near that many connections, of course, maybe 30-50 spare servers) |
| 10:14 |
ethomsen |
Quick question (although maybe not a quick answer) -- Why do we have separate boxes for barcode and username on the My Account password reset page, instead of a single box that can take either piece of data on the login screen? |
| 10:14 |
Bmagic |
Dyrcona: I have a theory that we have just hit capacity with our settings (based on that we have had apache CPU killing our VM's more frequently now and LVS is reporting 150 connections to each vm) |
| 10:14 |
ethomsen |
We're in a streamlining mood. |
| 10:15 |
Dyrcona |
Well, with 150 going we're using roughly half the RAM, but we cut the drones at 1000 requests to keep down memory use per drone. |
| 10:15 |
Dyrcona |
When we hit maxrequestworkers, the system scheduler goes nuts. |
| 10:16 |
Bmagic |
that's what we were dealing with on Thursday and yesterday! |
| 10:16 |
Dyrcona |
ethomsen: I can't really say why, but I think you could do it all in one box. |
| 10:16 |
Dyrcona |
For me, it was Friday, Saturday, and yesterday. ;) |
| 10:16 |
|
dbwells joined #evergreen |
| 10:17 |
jeff |
ethomsen: we moved to a single box in our setup. |
| 10:17 |
jeff |
ethomsen: i'd support making that change in Evergreen. |
| 10:17 |
Dyrcona |
So, I'm waiting for that to happen again, so I can install a new mpm_prefork.conf and restart Apache. |
| 10:17 |
jeff |
ethomsen: at least as an option, for those sites where it makes sense. |
| 10:18 |
Dyrcona |
Bmagic: Do you know what your load is, typically? |
| 10:18 |
* Dyrcona |
is curious. |
| 10:19 |
Dyrcona |
It tuns out that for Apache performance, splitting staff and public is a good idea. :) |
| 10:19 |
Dyrcona |
Staff is easier to manage with settings. |
| 10:20 |
Bmagic |
Dyrcona: it's hard to get a bead on it, CPU loads on the 8 VM's never go over 2 |
| 10:20 |
|
jvwoolf joined #evergreen |
| 10:20 |
Bmagic |
Each VM had 4GB of memory and 12 CPU cores. I upped that to 12GB and 12 cores just because we could |
| 10:21 |
jeff |
does that mean that your hypervisor is going to pause until 12 cores are available at the same time on the physical hardware, causing you larger problems? |
| 10:22 |
Bmagic |
it's only been in that config for 10 hours, but the VM's have not consumed much more than 4GB even though they have triple that now |
| 10:22 |
|
kmlussier joined #evergreen |
| 10:23 |
Bmagic |
jeff: I don't have any evidence to support that. I have never seen that behavior. We are using Hyper-V (if that helps) |
| 10:24 |
Dyrcona |
We have 24GB on this vm and 6 cores provisioned on this vm. |
| 10:25 |
Dyrcona |
I think we've left one or two cores unused by vms, so we're not "overloading" the hardware. |
| 10:25 |
Bmagic |
Dyrcona: are you able to get the app server to consume 24GB? |
| 10:25 |
Dyrcona |
Bmagic: This is just of apache, we have the drones running on another vm. :) |
| 10:25 |
Bmagic |
The CPU usage is so low, I am not concerned about overloading. There are 24 cores on the host |
| 10:26 |
Dyrcona |
Right now, the apache box is only using 3GB or so of RAM, but it often goes to 7GB or more. |
| 10:26 |
Dyrcona |
Only 40 apache drones running right now, so mem. use is low. |
| 10:26 |
Bmagic |
so, separating the staff clients involves using a different dns name? |
| 10:27 |
Dyrcona |
Bmagic: Yeah, one for staff clients, one for public. |
| 10:27 |
Dyrcona |
Our drone vm is using 3.7GB +/- buffers and cache. |
| 10:28 |
Dyrcona |
8.8GB including buffers and cache. |
| 10:29 |
Dyrcona |
Our brick layout is different: 1 vm for ejabberd and IIRC, the opensrf.settings drone, 1 vm for drones, and 1 vm for apache. |
| 10:30 |
Dyrcona |
SIP2 gets its own vm on the public side. |
| 10:30 |
Dyrcona |
On the staff side, the SIP2 vm is replaced by a utility vm that also runs drones for itself, but could be used by the other vms, if needed. |
| 10:30 |
JBoyer |
Maybe, just maybe, a mic designed to go INSIDE A KICK DRUM is not ideal for picking up normal speech in a meeting setting. That's a free tip for anyone out there that has to putz about with this sort of thing. |
| 10:31 |
JBoyer |
One more thing to figure out / fix. |
| 10:32 |
Bmagic |
if this problem continues to crop up, we might put the staff clients on a separate set of vms, not a bad idea |
| 10:33 |
Dyrcona |
Bmagic: Do you know how many staff clients you have usually? |
| 10:33 |
Bmagic |
I would guess roughly 100 |
| 10:33 |
Dyrcona |
We have about 130, AFAICT. |
| 10:33 |
Bmagic |
50 branches with 2 workstations on average |
| 10:33 |
Bmagic |
might be a little more |
| 10:33 |
Dyrcona |
You could probably do 1 smallish brick just for staff. |
| 10:34 |
Dyrcona |
Bmagic: You probably have closer to 200, but you know the size of your members better than I do. |
| 10:34 |
Bmagic |
you might be right |
| 10:36 |
Dyrcona |
Oh, I have a correction to make: 595 unique workstations were used over the past 6 months or so. |
| 10:36 |
Dyrcona |
I don't think we have more than 130 to 150 in use at any time. |
| 10:37 |
Dyrcona |
Anyway, you could very likely get away with a single brick for staff clients, and the rest for public. |
| 10:40 |
Dyrcona |
JBoyer: A little digging suggests that Evergreen's mod_perl code might need some work to function properly in a threaded environment. |
| 10:41 |
Dyrcona |
Not mod_perl, itself, but the way Evergreen uses mod_perl. |
| 10:41 |
Dyrcona |
It would take a day or two of testing to know for sure, though. |
| 10:41 |
|
ethomsen left #evergreen |
| 10:46 |
|
kmlussier joined #evergreen |
| 10:56 |
|
kmlussier joined #evergreen |
| 10:57 |
Dyrcona |
A little birdie :) reminds me that two bricks for staff would be safer in case one fails. |
| 11:05 |
Bmagic |
Dyrcona: yeah, we would use at least 2 |
| 11:05 |
Bmagic |
can you use the same lvs machine? It would seem that we would need to setup a different public IP for the pool and another lvs machine for it |
| 11:07 |
gmcharlt |
Bmagic: nothing prevents LVS/ldirectord from managing load-balancing for multiple public IPs |
| 11:07 |
Bmagic |
ah, there is a config there somewhere, Im sure I will cross that bridge when I get there |
| 11:14 |
jeff |
and i'm sure the documentation you consult will consist entirely of deprecated HOWTOs with various mailing list threads copied into their bodies. |
| 11:15 |
|
kmlussier joined #evergreen |
| 11:15 |
jeff |
has anyone here tried running hatch as a service under windows yet? |
| 11:21 |
terran |
jeff: I tried and failed a while back (December?) - sorry, I don't recall what problem I ran into |
| 11:21 |
jeff |
terran: do you recall what method you were trying? |
| 11:22 |
terran |
jeff: I think I blocked it from my memory |
| 11:22 |
jeff |
terran: fair enough! :-) |
| 11:23 |
|
Christineb joined #evergreen |
| 11:53 |
|
sandbergja joined #evergreen |
| 11:56 |
|
bmills joined #evergreen |
| 12:09 |
|
gsams_ joined #evergreen |
| 12:52 |
|
kmlussier joined #evergreen |
| 12:58 |
|
brahmina joined #evergreen |
| 13:07 |
|
jihpringle joined #evergreen |
| 13:18 |
|
miker joined #evergreen |
| 13:18 |
|
akilsdonk joined #evergreen |
| 13:18 |
|
phasefx_ joined #evergreen |
| 13:20 |
|
jyorio joined #evergreen |
| 13:20 |
|
rhamby joined #evergreen |
| 13:27 |
Dyrcona |
We just hit 150 apache drones on the vm and the scheduler did not go nuts. |
| 13:28 |
Dyrcona |
Of course, that lasted for less than a minute or two. |
| 13:31 |
|
TARA joined #evergreen |
| 13:37 |
JBoyer |
My google-fu is weak today. I've loaded some auth records and would like to link them to bibs, does that mean calling authority_control_fields.pl and/or something else? |
| 13:39 |
berick |
JBoyer: that's the one. |
| 13:40 |
JBoyer |
Sweet. Thanks. |
| 13:40 |
JBoyer |
berick++ |
| 14:00 |
|
jlitrell joined #evergreen |
| 14:05 |
JBoyer |
Another side project I'm working on is dates in emails. I can't tell what module date.format in a TT2 file is using (use date just blows up in perl, so I don't know where to look), so I tried going with strftime formatting commands. Now I have a bunch of invalid email events to wipe out and begin anew. :-/ |
| 14:05 |
* jeff |
continues thinking about and mucking about with Hatch |
| 14:05 |
JBoyer |
running a_t_runner.pl with verbose and debug-stdout isn't telling me much. :( |
| 14:05 |
jeff |
JBoyer: what are you trying to do? just format a date? |
| 14:06 |
JBoyer |
Yes, specifically the way it's defined in rfc822. |
| 14:06 |
JBoyer |
Which would be this: date.format(date.now, "%a, %d %b %y %T %Z") |
| 14:06 |
JBoyer |
But I suspect it's choking on part of it and nothing will actually complain at me. |
| 14:07 |
jlitrell |
Dumper it. |
| 14:08 |
JBoyer |
I'm not sure where to do that without dumping every email we send until I find it (in SendEmail.pm). I mean, that's an option if it comes to it, but... |
| 14:09 |
Dyrcona |
JBoyer: This is in a template, right? |
| 14:09 |
JBoyer |
Yes. |
| 14:09 |
jeff |
we have luck with: |
| 14:09 |
jeff |
[%- USE date -%] |
| 14:09 |
jeff |
[% IF hold.shelf_expire_time %]This item will be held until [% date.format(helpers.format_date(hold.shelf_expire_time), format = '%A %B %d') %].[% END %] |
| 14:10 |
jeff |
i wonder if you would benefit from helpers.format_date |
| 14:11 |
JBoyer |
I'm using date.now since that appears to work fine for the EDI templates. I'm not working with a specific date at that point, I want to add a Date: header. |
| 14:12 |
jeff |
ah, right. |
| 14:12 |
jeff |
already tried something like this? |
| 14:12 |
jeff |
Date: [% date.format(format => '%a, %d %b %Y %H:%M:%S %Z') %] |
| 14:14 |
JBoyer |
That was my next plan. I was hoping to find what [% use date %] was actually pulling in, but at this rate just trying again will be faster. |
| 14:14 |
jeff |
http://template-toolkit.org/docs/modules/Template/Plugin/Date.html |
| 14:15 |
JBoyer |
I do feel a bit daft now, I specifically searched for date on the TT site and wasn't finding that. :( |
| 14:17 |
jeff |
That's okay. One of the first times I used it, I managed to create output that was completely wrong. I think I was passing a wrong-but-not-wrong-enough value by not using the helper above... anyway, it resulted in output that looked valid but had little discernable relation with the input values. |
| 14:20 |
JBoyer |
Apparently just changing %T isn't enough. Now that I know it's calling POSIX::strftime I'll see what it claims to support. May require some locale coaxing, we'll see. I'll poke at it. If this solves the "My android phone puts all of your mail in 1969" problem I'll patch it up for master. |
| 14:21 |
|
tspindler1 joined #evergreen |
| 14:22 |
|
collum joined #evergreen |
| 14:25 |
* kmlussier |
tries to figure out why bug 1352542 didn't come up when somebody asked for advice last week on a patch to test for bug squashing day. |
| 14:25 |
pinesol_green |
Launchpad bug 1352542 in Evergreen 2.9 "Printing: LC Call number formatting (2.5.2)" [Undecided,Confirmed] https://launchpad.net/bugs/1352542 |
| 14:28 |
miker |
JBoyer: I think it's using http://template-toolkit.org/docs/modules/Template/Plugin/Date.html |
| 14:29 |
JBoyer |
Right-o. jeff pointed me in the right direction, now it's time for rabbit-hole-ing. :-/ |
| 14:29 |
* miker |
should read ALL the scrollback |
| 14:29 |
Dyrcona |
:) |
| 14:45 |
* Dyrcona |
thinks we need add 2 cores to our Apache vm. |
| 14:46 |
JBoyer |
Alright, I call shenanigans. I took the whole thing back out and they're all still invalid. Something else is up. Time to fake up a circ for myself. |
| 14:46 |
Dyrcona |
We can "steal" a couple from sip. |
| 14:46 |
Dyrcona |
JBoyer: I tested date.format(format = '%a, %d %b %Y %H:%M:%S %Z') in a template and it looks like valid RFC2822 dates. |
| 14:47 |
Dyrcona |
And, we peaked so far at 242 apache drones. |
| 14:47 |
Dyrcona |
JBoyer: Wed, 01 Jun 2016 14:47:39 EDT |
| 14:49 |
JBoyer |
Dyrcona, Thanks for the sanity check. It looks like the only circs that trigger this event belong to users without emails so I've been chasing my tail for a bit. |
| 14:49 |
JBoyer |
Dyrcona++ |
| 14:49 |
JBoyer |
jeff++ |
| 14:49 |
Dyrcona |
OK. Also, looks you might want something other than %Z for the time zone. |
| 14:49 |
JBoyer |
miker++ # An A for effort, ;) |
| 14:50 |
Dyrcona |
I see -0400 in actual emails and not EDT. |
| 14:50 |
JBoyer |
Both are ok spec-wise. I'm not terribly worried about the TZ in any case. |
| 14:51 |
JBoyer |
So long as it's in the correct century in their client I'm willing to let them drift a bit. |
| 14:52 |
Dyrcona |
Since I removed the MaxRequestWorkers (MaxClients) limit, we've stayed over 150, pretty much, with the occasional dip below 100. |
| 14:52 |
Dyrcona |
Well, you could just not add a Date: and 1) get flagged as spam more often, and 2) get set to Dec 31, 1969 in most mail clients. |
| 14:53 |
Dyrcona |
Crazy... numbers all over the place. |
| 14:54 |
JBoyer |
That's the point, We aren't sending any dates now. So clients that show the sent date dump us in the past, and clients that show the recieved date show us normally. |
| 14:54 |
Dyrcona |
Jump from 87 to 150, just like that.... |
| 14:55 |
Dyrcona |
Well, adding a date would be a nice thing to do. |
| 14:56 |
jeffdavis |
dev meeting in 5 minutes? |
| 14:56 |
kmlussier |
jeffdavis: You beat me to it. I was just about to post a reminder and ask for volunteers to lead. |
| 14:56 |
* kmlussier |
would volunteer, but needs to set up Sandboxes for tomorrow. |
| 14:58 |
Dyrcona |
JBoyer: I thought so: RFC 2822 requires the originator date field. |
| 14:58 |
Dyrcona |
IIRC, it is superseded by a more recent RFC. |
| 14:59 |
JBoyer |
That's why I'm trying to get it in place, I saw reference to it being required and thought it may be the solution to our longstanding (but primarily effecting Android users?) issue. |
| 15:00 |
JBoyer |
There's a newer rfc, but it probably doesn't hurt to include it anyway, apparently someone wants one now and then. |
| 15:01 |
kmlussier |
We should add a new @meetingchair plugin that randomly selects a person from the channel to run whatever meeting is happening at the moment. |
| 15:02 |
jeffdavis |
I guess I could try running the meeting... |
| 15:02 |
Dyrcona |
JBoyer: The newer RFC probably requires the date, too. |
| 15:02 |
* Dyrcona |
is expecting a server to meltdown. |
| 15:02 |
kmlussier |
jeffdavis: http://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot :) |
| 15:03 |
jeffdavis |
heh, thanks - let's see how this goes |
| 15:03 |
jeffdavis |
#startmeeting Evergreen Developer Meeting, 1 June 2016 |
| 15:03 |
pinesol_green |
Meeting started Wed Jun 1 15:03:11 2016 US/Eastern. The chair is jeffdavis. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:03 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:03 |
pinesol_green |
The meeting name has been set to 'evergreen_developer_meeting__1_june_2016' |
| 15:03 |
kmlussier |
jeffdavis++ |
| 15:03 |
jeffdavis |
#info Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-06-01 |
| 15:03 |
jeffdavis |
#topic Introductions |
| 15:04 |
jeffdavis |
#info jeffdavis = Jeff Davis, Sitka |
| 15:04 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:04 |
Dyrcona |
#info Dyrcona = Jason Stephenson, MVLC |
| 15:04 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:04 |
jlitrell |
#info jlitrell = Jake Litrell, MassLNC |
| 15:05 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:05 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 15:05 |
berick |
#info berick Bill Erickson, KCLS |
| 15:06 |
jeffdavis |
if anyone else joins, please introduce yourself as above |
| 15:06 |
jeffdavis |
# topic Action Items from Last Meeting |
| 15:06 |
jeffdavis |
er |
| 15:06 |
jeffdavis |
#topic Action Items from Last Meeting |
| 15:07 |
brahmina |
#info brahmina = Brahmina Burgess, Sitka |
| 15:07 |
jeffdavis |
first action item is "Dyrcona to write up bug report for nodejs installation item on Ubuntu 14.04", sounds like that is resolved? |
| 15:08 |
Dyrcona |
Yes. It was resolved by npm getting their act together. :) |
| 15:08 |
jeffdavis |
#info DONE: Dyrcona to write up bug report for nodejs installation item on Ubuntu 14.04 - resolved upstream by npm folks |
| 15:09 |
jeffdavis |
where are we at with Xenial support? is there more work to be done there? |
| 15:09 |
Dyrcona |
I don't think so. |
| 15:10 |
Dyrcona |
Ubuntu trusty and Debian Jessie could use a small patch that turned up in the Xenial work, but Xenial is working for me. |
| 15:10 |
berick |
xenial working for me too |
| 15:10 |
jeffdavis |
great! |
| 15:11 |
jeffdavis |
#info DONE: Dyrcona will work on Xenial Xerus Evergreen and OpenSRF support between now and the EG conference - thanks to Dyrcona, csharp, and bshum |
| 15:11 |
jeffdavis |
#info DONE: gmcharlt will send an email to the mailing lists announcing the Pg dependency change |
| 15:12 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 15:13 |
jeffdavis |
last action item was about Sqitch |
| 15:13 |
jeffdavis |
i.e. more detailed evaluation/testing thereof |
| 15:13 |
jeffdavis |
status according to the agenda: "Bill pushed a version of the Sqitch setup with a reified database (1 schema file and a handful of data files) for discussion. Confirmed Ubuntu 16.04 has a Sqitch package. Need to explore release-building options (presumably via 'sqitch bundle –from foo –to bar'). Probably other stuff too." |
| 15:14 |
jeffdavis |
Is there anything else to add or discuss there for now? |
| 15:14 |
Dyrcona |
I'd call that "in progress." |
| 15:14 |
Dyrcona |
For the sake of the minutes. |
| 15:14 |
berick |
'in progress' sounds good |
| 15:15 |
jeffdavis |
shall we capture those details in the minutes as well? |
| 15:15 |
Dyrcona |
I'd just say in progress: action item. |
| 15:15 |
Dyrcona |
I don't think the minutes need the detail. |
| 15:16 |
Dyrcona |
It'll be in the logs and the agenda. |
| 15:16 |
jeffdavis |
#info IN PROGRESS: evaluation/testing of Sqitch |
| 15:16 |
miker |
#info miker = Mike Rylander, ESI |
| 15:17 |
jeffdavis |
#action developers to continue looking at Sqitch, particularly release-building options |
| 15:17 |
jeffdavis |
#topic OpenSRF release |
| 15:18 |
gmcharlt |
so, there are some patches in the queue that I need to review |
| 15:18 |
gmcharlt |
and ensure that OpenSRF master will build all on all of the target platforms |
| 15:19 |
gmcharlt |
I've also got some pull requests that I may tap some people to review |
| 15:19 |
gmcharlt |
but upshot, we can plan on a release before ALA Annual, in both the 1.5 and 1.4 series |
| 15:20 |
jeffdavis |
gmcharlt: sorry, 1.5 and 1.4 series? |
| 15:20 |
miker |
s/1\.(\d)/2.$1/g |
| 15:21 |
jeffdavis |
ah perfect |
| 15:21 |
gmcharlt |
er, yeah, what miker said |
| 15:21 |
* jeff |
arrives |
| 15:21 |
gmcharlt |
Announcing OpenSRF random() ! |
| 15:22 |
* miker |
gets his delorian out of the garage |
| 15:22 |
jeff |
#info jeff == Jeff Godin, Traverse Area District Library (TADL) |
| 15:22 |
jeffdavis |
#action gmcharlt to review a few outstanding OpenSRF patches/pull requests |
| 15:23 |
jeffdavis |
would the 2.5 release be an alpha/beta, or do we expect to have 2.5.0 ready by ALA? |
| 15:25 |
jeffdavis |
#info New OpenSRF releases for both 2.4 and 2.5 are expected before ALA Annual in late June |
| 15:26 |
gmcharlt |
jeffdavis: depends on what I see in the patches |
| 15:26 |
gmcharlt |
but at most there would be a beta prior to the 2.5.0 release |
| 15:27 |
* jeffdavis |
nods |
| 15:28 |
jeffdavis |
moving on... |
| 15:28 |
jeffdavis |
#topic Evergreen release |
| 15:28 |
miker |
I'll have a firm proposed schedule for the list tomorrow. don't expect it to deviate much from last summer's |
| 15:29 |
dbwells |
I've got a TODO to send an introductory email to my fellow buildmasters plus miker, nothing too involved, but a stake in the ground at least. Feel free to add as an action item. |
| 15:29 |
miker |
dbwells: that's be great |
| 15:29 |
miker |
and, with the schedule, a list of likely branches I hope to see merged |
| 15:30 |
miker |
and, secondarily, a list of possible upcoming tickets lacking pullrequests |
| 15:31 |
miker |
and, thirdly, but not least-ly, a bugs-we-should-really-finally-finish list |
| 15:31 |
miker |
the first list being features with pullrequests |
| 15:32 |
miker |
if anyone has specific strong desires, I'm happy to lend my RM poking stick to the effort. also, poke me if I miss something you really want/need |
| 15:33 |
* kmlussier |
never realized a poking stick came with the RM position. |
| 15:33 |
miker |
kmlussier: it's a very floppy stick |
| 15:33 |
miker |
+0 damage |
| 15:34 |
kmlussier |
:) |
| 15:34 |
gmcharlt |
comes from the same box as the noodle lash |
| 15:34 |
jeffdavis |
miker++ |
| 15:34 |
kmlussier |
miker++ |
| 15:35 |
Dyrcona |
Sounds like miker gave himself an action to send an email to the lists.... |
| 15:35 |
miker |
Dyrcona: I did, indeed |
| 15:35 |
jeffdavis |
#action miker will email the list with a proposed schedule for 2.11 and a list of pending bugs/pullrequests |
| 15:35 |
Dyrcona |
miker++ |
| 15:35 |
jeffdavis |
#action dbwells will email the list with an introduction to the 2.11 release manager and buildmasters |
| 15:36 |
dbwells |
jeffdavis: actually not the list, just some internal coordination |
| 15:36 |
miker |
jeffdavis: that second one may not be a list email... dbwells? |
| 15:36 |
miker |
heh |
| 15:36 |
jeffdavis |
#action dbwells will send an introductory email to the 2.11 release manager and buildmasters |
| 15:36 |
jeffdavis |
#action jeffdavis will read IRC more carefully |
| 15:36 |
jeffdavis |
:P |
| 15:37 |
jeffdavis |
anything else on EG releases before we move on? |
| 15:37 |
Dyrcona |
:) |
| 15:37 |
miker |
not from me |
| 15:38 |
jeffdavis |
ok, on to new business then |
| 15:38 |
jeffdavis |
#topic Defining Bug Fixes and New Features |
| 15:39 |
jeffdavis |
Dyrcona: I think this was your agenda item |
| 15:39 |
Dyrcona |
Most of what I have to say about it is summarized in point 2, 3, and 4 in comment 38 from the Agenda. |
| 15:39 |
Dyrcona |
#link https://bugs.launchpad.net/evergreen/+bug/1501781/comments/38 |
| 15:39 |
pinesol_green |
Launchpad bug 1501781 in Evergreen "Patron name search should be diacritic-insensitive" [Wishlist,Confirmed] - Assigned to Terran McCanna (tmccanna) |
| 15:40 |
Dyrcona |
We don't have any actual rules about we do or do not backport as far as fixes go, and it might be helpful to clarify a few things. |
| 15:41 |
dbwells |
I think that comment it a pretty good summary, and I agree with all of it in the sense of making them guidelines. |
| 15:41 |
miker |
IMO, I'd go futher and say that anything that changes the db for reasons other that wrongness or broad performance (index or such) should have a high bar for backport |
| 15:41 |
kmlussier |
I'm okay of identifying guidelines for what should be considered a bug fix / new feature. But I think some judgment should be used too. If something is a bug, it's a bug, even if the fix requires the introduction of a new string. |
| 15:41 |
kmlussier |
okay *with* |
| 15:42 |
gmcharlt |
I agree that judgment must be permitted on the part of the rmaints |
| 15:42 |
Dyrcona |
Yeah, I'm not trying to usurp any power from maintainers. Ultimately, it should be their call. |
| 15:44 |
gmcharlt |
to respond to a couple points in Dyrcona's comments on the LP |
| 15:45 |
gmcharlt |
#1 - whether or not this is a bug kinda depends on one's locale, no? I think things that increase usability for non-EN locales should get some leeway |
| 15:45 |
gmcharlt |
#2 - the inability to easily get string changes for maintenance releases is, IMO, more reflective of a weakness in our translation infrastructure than anything else |
| 15:46 |
gmcharlt |
not that I'm offering an immediate solution, mind you |
| 15:46 |
gmcharlt |
so I guess one question I have: what problems are we specifically trying to solve by limiting what gets backported as bugfixes? |
| 15:47 |
gmcharlt |
to be sure, I don't disagree with the general notion that new features generally should not be backported into maintenance releases |
| 15:47 |
Dyrcona |
I think one issue we have is, "what is a bug?" There is often disagreement. |
| 15:48 |
gmcharlt |
so, some things I think we could have a quick consensus on |
| 15:48 |
gmcharlt |
so, a couple suggestions along those lines |
| 15:49 |
gmcharlt |
1. security issues may potentially trump other considerations |
| 15:50 |
gmcharlt |
2. something that that adds a new depency (in the form of a Perl module or APT or RPM package) should not be backported without extreeme provocation |
| 15:51 |
gmcharlt |
with the motivation for ^^ being a more general principle that "maintenance release upgrades should be quick, easy, and unsurprising to the sysadmin" |
| 15:51 |
gmcharlt |
is this useful as a starting point? |
| 15:51 |
jeff |
seems quite reasonable so far. |
| 15:52 |
kmlussier |
Yes, I agree with everything above |
| 15:52 |
jeffdavis |
+1 |
| 15:52 |
miker |
+1 |
| 15:52 |
gmcharlt |
3. (in agreement with Dyrcona) things that add YAOUS are generally not candidates for backporting |
| 15:53 |
kmlussier |
+1 |
| 15:53 |
gmcharlt |
(and a side note on dependencies in general: I'm a big fan of *not* adding new dependencies unless there's no other reasonable way to add functionality) |
| 15:53 |
Dyrcona |
+1 |
| 15:54 |
miker |
can that be generalized to "things that change existing correct behavior are not bug fixes", with the key being "correct" for some reasonable definition? |
| 15:54 |
miker |
or is that a bridge too far |
| 15:54 |
gmcharlt |
4. anything that *requires* that the EG admin do something post-upgrade should be discouraged from being backported |
| 15:55 |
gmcharlt |
miker: well, "correct" is kinda the sticking point :) |
| 15:56 |
kmlussier |
miker: the definition of 'existing correct behavior' is a squish as the definitions for bug and new feature IMO. I've seen many people say something is incorrect that probably meets your definition of 'existing correct behavior.' |
| 15:56 |
gmcharlt |
but to take the example of bug 1501781, I would give more weight if (say) the Czech folks chimed in and said "we really need this sooner rather than later" |
| 15:56 |
miker |
fair |
| 15:56 |
pinesol_green |
Launchpad bug 1501781 in Evergreen "Patron name search should be diacritic-insensitive" [Wishlist,Confirmed] https://launchpad.net/bugs/1501781 - Assigned to Terran McCanna (tmccanna) |
| 15:56 |
* kmlussier |
needs to run, but generally likes where this discussion is going. |
| 15:57 |
kmlussier |
jeffdavis: We can defer my agenda item to the next meeting. There's no rush on it. |
| 15:57 |
jeffdavis |
kmlussier: ok noted, thanks |
| 15:57 |
kmlussier |
jeffdavis++ |
| 15:57 |
jeffdavis |
gmcharlt: do you have further points to suggest beyond your #4 above? |
| 15:58 |
gmcharlt |
jeffdavis: nothing organized, and I've been monologuing enough anyway :) |
| 15:58 |
jeffdavis |
ha ok :) |
| 15:58 |
jeffdavis |
it seems to me there is a general consensus on the points discussed |
| 15:59 |
jeffdavis |
Dyrcona: do you feel like this addresses the concerns you've had? Any concerns or anything more you want to raise here? |
| 15:59 |
Dyrcona |
I don't have anything to add. |
| 15:59 |
dbwells |
I see whatever comes of this as a "Considerations for Backporting" page, to help everyone remember and recognize the pros and cons to an invariably squishy process. |
| 16:00 |
|
tspindler1 left #evergreen |
| 16:00 |
jeffdavis |
How do we want to capture this for future use? Anyone want to volunteer to summarize these points on a wiki page, for example? |
| 16:00 |
gmcharlt |
if Dyrcona wants, I'd be willing to volunteer to work with him on such a thing |
| 16:01 |
Dyrcona |
Sounds good to me. |
| 16:01 |
gmcharlt |
(as I think we kinda represent somewhat contrary views, so hopefully the squishy middle we'd end up with would be good, as it were :) ) |
| 16:02 |
jeffdavis |
#action gmcharlt and Dyrcona to summarize results of this discussion on the wiki for future use by release maintainers |
| 16:02 |
jeffdavis |
Dyrcona++ |
| 16:02 |
jeffdavis |
gmcharlt++ |
| 16:02 |
jeffdavis |
moving along |
| 16:02 |
jeffdavis |
#topic Mentoring new developers in the community |
| 16:02 |
jeffdavis |
#info Discussion deferred to next dev meeting |
| 16:03 |
jeffdavis |
#topic Recent config changes affecting ingest speed |
| 16:03 |
jeffdavis |
dbwells, want to speak to this? |
| 16:03 |
dbwells |
yes, one moment |
| 16:04 |
* Dyrcona |
wishes that branch existed over 72 hours ago. :) |
| 16:04 |
dbwells |
Has anyone taken a look at the change? |
| 16:04 |
jeff |
I have. |
| 16:04 |
jeff |
Looks reasonable. |
| 16:04 |
miker |
as have I. I like it |
| 16:04 |
jeff |
And a good way to cope with the 2234% increase in rows in crad. :-) |
| 16:05 |
dbwells |
Alright, maybe that's enough for now. I will create a bug for it, and post a few extra thoughts there. |
| 16:05 |
Dyrcona |
I've looked at the code, and have a slow server that it would be perfect to test on. |
| 16:05 |
miker |
not sure if an index would actually matter, but might be worth testing |
| 16:05 |
Dyrcona |
I even have timings for comparison-sake. |
| 16:06 |
dbwells |
miker: Yes, an index on ctype also helps, so that's a secondary play. |
| 16:06 |
jeffdavis |
#action dbwells to create a bug report for discussing some proposed ingest speed improvements |
| 16:06 |
jeffdavis |
dbwells++ # looks promising to me! |
| 16:07 |
jeff |
I think I was seeing a roughly "12x slower" record attr ingest with 2.10 when I was measuring timings, so a "7x better than that" is quite promising. |
| 16:07 |
dbwells |
One question I'll want more input on is whether we should flip the 'filter' flag off for some of the new rows by default, especially those which don't index anything. |
| 16:08 |
Dyrcona |
my record attr ingest that I started Sunday, took 67 hours to complete, on the "slow" server. |
| 16:08 |
dbwells |
It would be belt + suspenders at that point, but maybe worth not tripping over again down the road. |
| 16:08 |
jeff |
if they don't index anything, is the filter bit being set just an error? |
| 16:08 |
dbwells |
filter is true by default, so an error of omission if anything. |
| 16:08 |
dbwells |
But I can't read minds! |
| 16:09 |
|
bmills joined #evergreen |
| 16:09 |
dbwells |
I know we're over time already, and I think bugs are a better place to capture stuff like this anyway. Just wanted a quick reaction before heading down that route. Thanks, all. |
| 16:09 |
jeff |
dbwells++ |
| 16:09 |
jeffdavis |
thanks dbwells |
| 16:10 |
miker |
dbwells++ |
| 16:10 |
jeffdavis |
#topic Feedback for New Features Under Development |
| 16:10 |
jeffdavis |
bug 1373690 was mentioned on the agenda - berick, is that you? |
| 16:10 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 16:10 |
berick |
that's me |
| 16:10 |
berick |
trying to kill the bug that won't die |
| 16:10 |
berick |
hoping to make significant changes to how we generate EDI |
| 16:11 |
berick |
need sample data from the wild to be sure the new code is covering edge cases |
| 16:11 |
* Dyrcona |
can have a look. |
| 16:11 |
berick |
in short, moving all logic into Perl and out of the A/T templates |
| 16:12 |
jeffdavis |
berick: I'll pass that one along to our support folks to see if we can test |
| 16:12 |
berick |
beware to test, you have to install the new code (obviously, i guess) which includes some new DB tables |
| 16:12 |
berick |
and data |
| 16:12 |
berick |
the code does not yet have a UI for tweaking settings. that will come later |
| 16:13 |
berick |
wanted to be sure this is on the right path first |
| 16:13 |
berick |
thanks Dyrcona and jeffdavis |
| 16:13 |
berick |
i'll copy the "how to test" instructions from the agenda to the bug |
| 16:13 |
jeffdavis |
berick++ |
| 16:13 |
Dyrcona |
berick++ |
| 16:14 |
jeffdavis |
Any other new features to discuss before we adjourn? |
| 16:16 |
jeffdavis |
ok, that's it then - thanks everyone! |
| 16:16 |
berick |
thanks jeffdavis! |
| 16:16 |
jeff |
jeffdavis++ |
| 16:16 |
jeffdavis |
#endmeeting |
| 16:16 |
pinesol_green |
Meeting ended Wed Jun 1 16:16:58 2016 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:16 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-06-01-15.03.html |
| 16:16 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-06-01-15.03.txt |
| 16:16 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-06-01-15.03.log.html |
| 16:17 |
Dyrcona |
jeffdavis++ |
| 16:17 |
miker |
jeffdavis++ |
| 16:17 |
gmcharlt |
jeffdavis++ |
| 16:17 |
dbwells |
jeffdavis++ |
| 16:17 |
remingtron |
jeffdavis++ |
| 16:18 |
jeffdavis |
sweet sweet karma :) |
| 16:21 |
Dyrcona |
:) |
| 16:26 |
Bmagic |
jeffdavis++ |
| 16:45 |
|
mmorgan1 joined #evergreen |
| 17:04 |
* jeff |
revits ng-cloak |
| 17:04 |
jeff |
seems to work well, as theorized back in http://irc.evergreen-ils.org/evergreen/2015-10-07 |
| 17:34 |
|
mmorgan1 left #evergreen |
| 17:42 |
|
sarabee joined #evergreen |
| 17:44 |
|
jvwoolf left #evergreen |
| 18:06 |
jeffdavis |
jeff: did you end up filing a bug report for that SIP issue? |
| 18:15 |
|
barbara joined #evergreen |
| 18:43 |
|
gmcharlt_ joined #evergreen |
| 19:26 |
|
gmcharlt joined #evergreen |
| 20:20 |
|
jihpringle joined #evergreen |
| 20:59 |
|
yboston joined #evergreen |
| 23:11 |
|
eady joined #evergreen |
| 23:49 |
|
JBoyer_alt joined #evergreen |
