#metabrainz

I don't think there's a way to automatically reload the plugin, the fastest way I know is to drag the file into the plugins window again

@bitmap okay, i guess that's faster than navigating to the file every single time

I think i did it three hundred times while trying to get this thing to work :)

ouch :)

so the other question i had was

right now I made the plugin trigger on user action

saw some other plugins use register_track_metadata_processor instead

but couldn't figure out how that's supposed to trigger

or whether one makes more sense than another

those run automatically right after the release loads iirc

leftmostcat pushed 2 commits to bookbrainz-data-js: https://github.com/bookbrainz/bookbrainz-data-j...

leftmostcat pushed 2 commits to bookbrainz-site: https://github.com/bookbrainz/bookbrainz-site/c...

leftmostcat pushed 1 commits to bookbrainz-site: https://github.com/bookbrainz/bookbrainz-site/c...

LordSputnik, I don't think I have a link to the doc on updating rika. Could you send that my way when you're on next?

Also, I have an inkling of an idea on how to deal with revisions. Instead of creating them directly with a create function, we do it with a trigger on saving an Entity or EntityData instance.

Good morning, Rob

awesome network is awesome.

Heh. Where are you this time?

at the uni.

and this is the worst network connection in weeks. :(

oh hai

hey

hey

:))

whooops roobarb tipped over. :(

been pretty stable recently, though

a both tipped over.

zas: you on that or should I log in?

please do, i'm on gateway-chef atm

k

i found an annoying bug in crm

it concerns the modgroup command, which doesn't do what it should, not preserving the order in the group after you commit

gah network lag. :(

if you have group G A B and modgroup G add C before B, it works (crm configure show: G A C B) but when after the commit it is set to G A B C ... and since order in the group is very important, it mess up the setup

i didn't search yet if it is a known issue (perhaps fixed in later versions)

in fact group is working like colocation + order, so they are redundant if used together (ie. initial setup you made)

ruaok: to recover you need to reduce rate limiter value to 500 ie

else it will not work :(

500?

wow.

500, then let search servers recover, then move it back to original value

it used to be 1000

you can try 1000, but last time i had to go even further down

1000 didn't work, on 500 now

this is damn annoying

still not recovering.

try to stop one server, and let the other going up (it takes 7-8 minutes)

this is incredible they can't recover by themselves... we need to find a way to slow start them, bitmap suggested to use the rate limiter for that, though i have no idea yet on how to set up something simple enough to be reliable

I dont think slow starting them is all the hard.

but another approach would to find WHY they suddenly crash, and fix the issue at the root

ok, recovered now

so, in order to cold start a search server we just need to write a script that executes searches on each of the indexes.

pick a random dictionary word, do a search, repeat.

do that for X times on each index and things should be safe enough to restart.

we need to block requests until the slow start process is finished

that part is harder. :(

a simple iptables rule could do

with a REJECT

and then nginx would fail out that search server.

nice idea. :)

block, start server, do slow start queries, unblock

ok both servers are back to business, until next crash

about gateway-chef, i'm working on the pacemaker config, and it is a damn hell, but i'm now knowing much more about it

rule: it doesn't work as you think it works ;)

there is a lot of know. :(

oy

plus it has bugs

small ones, annoying ones

i rewrote all cookbooks, so they play nicely now

<3

thank you!

i can install both gateways on VMs easily, but the crm config isn't ready yet

i'm thinking about not using groups at all

dnscache / tinydns depends only on one internal IP

mx/mail IPs are independent from the rest (well, i think...)

nginx / rate limiter depends on both external IPs and few internal IPs

tinydns has to start before dnscache (since it forwards requests to tinydns)

we have 2 possibilities, either all resources can run anywhere by default (meaning they start as soon they are configured), or the reverse which implies to explicitely define where they can run, more complex but it ensures no resource is started until we say to

also i found a nice thing

I always wondered about all the IPs we use.

ifconfig doesn't report configured interfaces

ip command does

would everything be simpler if we used 1 IP for everything?

but there is a way to have them displayed, using iflabel in primitives

one IP ?

we currently have 5 or so IPs that can fail over.

would it be easier with 1 and have all the services on 1?

it will prolly easier, though i think i can make it work as is

basically if a service fails (or an IP) we migrate all to the other server anyway

exactly. :)

this is something that was not working, ie. if dnscache failed, all were stopped ...

now the thing i didnt do yet, is deep checks: we currently test the services are running ... not they are working (nginx can run, and still not answering ie.)

i prepared what is needed to do that, we can add an extracheck=program for each service

feh, I need to buy is the irccloud package. but I can't think straight, so hungry.

back in a bit.

obviously each check program is different, depending on what we check (dns requests / web requests)

and there is a way to use nagios plugins

i didnt test that yet

the whole thing is huge ;)

Freso: ping

greetings from copenhagen