#metabrainz

[bookbrainz-site] LordSputnik opened pull request #614 (master…master): chore: drop support for node 10, which is EOL today https://github.com/bookbrainz/bookbrainz-site/p...

Still no yvanzo :(

ruaok: I had already done that a few weeks ago. I was unable to add a star though probably because only org admins can do that?

tagging okno_ also on the GSoC application review

https://twitter.com/charlottejee/status/1387722... lol 😆

hi nelgin, I can have a look at it, please PM for details.

Hi. Sure.

details sent. Thank you.

Custom memory settings have been correctly applied, there is no issue there.

About missing queues: rabbitmq is creating a new database directory on startup, based on hostname.

That is a new behaviour for rabbitmq Docker image, compared to what it used to be.

That explains I could not reproduce the issue: I was still using previous image.

So, we have to set a fixed hostname for 'mq' service and that should solve it.

ok, can I do that here to test?

or not sure if you're able to push a fix?

added local/compose/fix-mq-persistence.yml

OK, do I need to configure add that or did you do it?

yvanzo ok, that fixed that problem I'm seeing the queues after the restart of docker-compose

Running replication.sh and then I'll check the queue

I did add that, stopped live indexing, ran amqp_setup again, down everything, readd live indexing, and up everything again.

'admin/configure add' handle duplicates, so no worry about having done that more than once.

Very good. It's working the queue right now. I forgot to increase the indexer.ini value. I'll do that once this has finished, and we'll see if the settings stick.

Feel free to stop/remove the indexer, update its configuration and start it again. RabbitMQ will keep storing reindex messages in the meantime, so that live indexing is able to resume.

[musicbrainz-server] reosarevok opened pull request #2080 (master…MBS-11631): MBS-11631: Unblock label and place links in DNB validation https://github.com/metabrainz/musicbrainz-serve...

yvanzo, bitmap^ seems to be a new regression, might not be worth rushing it into this next release since it's relatively minor, but let's get it for the next :)

ruaok: there was an alert on cpu temp for gaga, the load at this time was higher than usual, but not that high, I suspect a cpu fan failure (surprise!) (and too bad we can't gather cpu fan speed on those machines). It runs mainly lb stuff. We should ask for a tech to look at it. Can it be stopped for few minutes? preferred time frame?

yvanzo, I got 3 of these messages in my indexer log:

Index limit exceeded. Entity: release, Total Rows: 210617, Extra Data: {'path': 'artist_credit', 'table_name': u'artist_credit', 'select_query': 'SELECT release_1.id AS release_1_id \nFROM musicbrainz.release AS release_1 JOIN musicbrainz.artist_credit ON musicbrainz.artist_credit.id = release_1.artist_credit \nWHERE musicbrainz.artist_credit.id = :id_1'}

well, this pretty much means downtime for LB.

search.failed | 3

zas: I am responsible for the extra load, I can stop that.

well, the extra load isn't the issue, it was something like 40% cpu, but the cpu temp raised > 95°C so very likely a cooling problem (=cpu fan, we are used to that now...)

I'd rather not take the whole site down for the fan upgrade. I'm considering some code improvements to allow the timescale to be offline, without having to take LB down. that way we can still accept listen submissions, but not show listens on the site for the duration.

that's not urgent, but the hardware has to be fixed at some time

ok, I'll stop the process that puts on the extra load, and start working on this so we can make the fix early next week.

how is that for a plan?

ok for me :)

kewl.

Gets my vote ;)

yvanzo, really need to sort this crontab problem out, if you have the time. It;s 4am here so I can't stop up much longer.

yvanzo https://pastebin.com/SLj14J6i

nelgin: there is nothing related to the crontab under local/compose/

When I run crontab -l, I get the default crontab as expected.

I'm just doing what it says here.

Ok, let me restart musicbrainz service

Mr_Monkey: please to pare down GSoC proposals soon, ok?

Yes yes, I've been reading the proposals throughout the week, will make final decisions now

can you start setting proposals that you are clearly not going to accept to "ignore"?

Sure thing

thx!

ruaok: I had tried earlier but thought it was too early: I can't set proposals as ignored. Maybe I don't have rights?

yvanzo did you add the crontab manually?

I can't give perms for that.

PM me the titles of proposals to mark as ignore.

only org admins can do that afaik (star or ignore proposals)

nelgin: it still works after restart, after stop/start, after down/up

no, I did not add it.

Hmm, maybe I was being too hasty.

Ok. I'm going to change it to replicate every hour then.

That is possible: it can take a few minutes before the container sets the crontab and starts cron.

I released an update for MuiscBrainz Android yesterday which is now live on Play Store with akshaaatt[m]'s bugfix for a long standing bug in the Tagger.

!m akshaaatt[m]

You're doing good work, akshaaatt[m]!

shivam-kapila: want to give it a try? :)

outsidecontext: zas: is that picard GSoC proposal on your radar?

yvanzo I created local/compose/replication.cron and added the path into .env

grep CRON .env

MUSICBRAINZ_CRONTAB_PATH=/restore/musicbrainz/musicbrainz-docker/local/compose/replication.cron

sudo docker-compose up -d

and there's no crontab. Checked for the last 2 minutes.

ruaok: I commented on the proposals relevant to me

ruaok: nope, haven't seen it yet :( It's on my radar to look into the GSoC dashboard, though.I think I had hoped there would be some kind of notification if there is a proposal

Interesting, as soon as I login to the bash shell, there it is.

I don't get it, but it's 430am so I'm going to bed, but something's not right, going to restart the container and then check when I get up.

Ok, good night.

meh, forgot to use -d when I started it. Oh well. It'll be ok.

ruaok: alastairp: regarding lb username change, till we do not support it i was thinking we could provide a script for users. like the user could download their export from their profile delete their listens, point the script to the exported json file and put their new username token etc. and submit their listens.

hmm. we could do that. but how important is that for us right now? enough to write this script?

ruaok, outsidecontext: I read it yesterday (got no notification either), as is, not very detailed, but we don't have any other Picard-related proposal afaik, so I'm ok to co-mentor (with outsidecontext?). Is proposal's author hanging around (dhhruv) ?

_lucifer: this should be something that we do in the backend. if someone requests it we can just perform an sql query, or write a quick migration script ourselves to do it

without having to delete/reimport all of the content

(although you raise a good point, perhaps this is an easier way of doing it without locking the database)

alastairp: did you see zas' comment about the fan replacement on gaga?

I just did

I agree with your proposal to make LB run without the database

great.

which is great, because it ties in nicely with our discussion on wednesday about being about to start up services without dependencies, too

I'm wondering on how to go about doing that.

yeah there are multiple ways to do it, i was looking into the easiest one without affecting the backend. i am not sure about the urgency of this though, i raised this because of a support email reo asked me about.

I guess it should just be automatic. If the listenstore is not available, then set a flag and return 503 for API calls that touch the listenstore.

ruaok: I'm just saying the first thing that comes to mind: if no db configuration, set an empty listenstore or set it to None; then have a @decorator which checks if the listenstore is available and if not, returns an error early

OH. great idea.

that should work well for API endpoints. some website endpoints also query listenstore directly

so that'll need some additional checks

agreed.

I'll start working on that in a bit.

now that gsoc is somewhat tucked away.

nelgin: local/compose/ is supposed to contain .yml compose files, not crontab file.

Ah my bad. Fixed.

You can turn it off as it seems to work now.

Maybe

MUSICBRAINZ_CRONTAB_PATH=/restore/musicbrainz/musicbrainz-docker/local/replication.cron

Then I should be able to do sudo docker-compose up -d right?

yes

at least, 'crontab -l' currently returns the same content as this file.

Yup, it's good.

zas, rdswift: FYI, I rebased the 2.7.x branch and merged it into master. As we don't plan another 2.6.x release we can continue there (if we should need to do a 2.6.3 unexpectedly we'll have a release branch for that)

ok, thanks

outsidecontext: I sent a mail to Dhruv (about GSoC/Picard), asking him to contact us here (may be he's around, but I don't know under which nickname)

zas: thanks

community.meb is down

on it

[musicbrainz-docker] yvanzo opened pull request #192 (master…fix-mqdata-persistence): MBVM-69: Fix persistence of search message queues https://github.com/metabrainz/musicbrainz-docke...

_lucifer: can I get a review on https://github.com/metabrainz/brainzutils-pytho... ?

[brainzutils-python] alastair merged pull request #66 (master…incr-amount): Allow increment to take an optional amount value https://github.com/metabrainz/brainzutils-pytho...

on it 👍

I'll look at the sets and pending cache changes

Mr_Monkey: got an error on beta while testing error handling of youtube player, the error didn't show up in sentry but console has some info

_lucifer: I'm not having any luck getting spark-request-consumer on michael running again. the container is created, but not started. then it just hangs. any ideas?

ruaok: let me login and take a look.

community.meb is back

the dump has finished and I want to do a full import now. (even though we'll generate a new dump tomorrow, but hey)

_lucifer: thanks

ruaok: request consumer is up.

you need to run to start it correctly ./docker/spark-new-cluster/start-request-consumer-container.sh

and ./docker/spark-new-cluster/stop-request-consumer-container.sh to stop and cleanup

i'll document this.

Mr_Monkey: console log of the error ^

_lucifer: ok, thanks.

Mr_Monkey, I was testing what happens if user externally revokes the youtube access. the server should handle it and probably respond with 401 or 403, i think?

_lucifer: full dump into spark requested.