#metabrainz

that's it for me

bitmap: next?

_lucifer: https://musicbrainz.org/release-group/cecf0c16-... ;)

heya

welcome to the meb team _lucifer!

hehe

thanks bitmap!

last week I was still fixing bugs in the relationship editor / autocomplete components and working on integrating them into the release relationship editor, while trying to resolve parts of MBS-7981

MBS-7981: Unify relationship editor and mini relationship editor interfaces https://tickets.metabrainz.org/browse/MBS-7981

later in the week I submitted a fix for MBS-11410 and did some investigation into MBS-10896, the latter of which I think I have a good idea on how to resolve so that we can remove a lot of lock contention on the vote table

MBS-11410: Edit could not be created while at the same time approving another one had a time-out https://tickets.metabrainz.org/browse/MBS-11410

MBS-10896: ISE when voting: LOCK vote IN SHARE ROW EXCLUSIVE MODE https://tickets.metabrainz.org/browse/MBS-10896

other than that, I was helping test gitzconsul a bit more, which I need to follow up on today, and was continuing to tidy up commits from the relationship editor branch so I can submit those in smaller pieces

fin! zas: goo

Hey

usual bunch of required upgrades

I also refined few blacklists to save a bit of bandwidth / cpu

I reviewed a bunch of Picard PRs (a new release should occur tomorrow)

(Only myself left on my list – last call for anyone else who want to give review!!)

and worked on stabilizing gitzconsul (thanks bitmap for the feedback)

that's it for me. Freso?

👋

Mostly the usual. Lurking around and such. Also attended board meeting and noted that the board approved of a new hire. :p Welcome _lucifer! :)

thanks Freso :D

fin.

Which wraps up tonight’s reviews! Thank you everyone who gave one. :)

We have two additional items on tonight’s agenda…

zas: MB website performance

We had an issue few days ago

basically an increase of number of requests to the MB website

this was handled very badly by our systems, leading to huge load on all nodes + floyd

I was really hoping that we would've had a more efficient web page setup by now.

looking at numbers, the increase was significant, but the absolute number wasn't that huge: basically ~100 req/s handled by 7 backends

a non trivial number of pages have been moved to react, which we thought would improve things. but clearly it has not.

so basically 10 req/s and poooof

bitmap: can you please have someone (or yourself) investigate why things are as bad as they are?

are we loading too much data from postgres and never using it?

yes, that is possible. do we know which pages were being requested?

we should've seen a drastic improvement after so much time spent working on react

zas: can you please open a ticket that gives an idea which pages were affected?

Are they all requesting relationships for Bach and NYC?

I'll look into it, but the bottleneck might not have been TT in this case

not really because it's not complete yet

hmmm; that's the thing, many different pages from many different IPs, hard to find a pattern, but I'll try to provide what I can

some pages are just slow becase of the amount of information requested

yvanzo: understood its not done yet, but I dont think any of these requests were made by logged in users. so unlikely to be unfinished edit stuff.

Yeah, but if there's many different ones that are all slow, it's weird

ruaok: right

not sure there is much more to say about this topic now.

zas makes a ticket and provides as much info as possible and then we'll see what comes from that.

k

That sounds reasonable.

yep, I'll follow-up on the ticket

unless there is anything else on this topic, back to freso.

kewl, thanks!

Alright, let’s move to last agenda item for this meeting!

reo: MBS-9733 / MBS-6344

MBS-9733: Display editor last activity date in user account general information https://tickets.metabrainz.org/browse/MBS-9733

MBS-6344: Show when users were last active on editor subscriptions page https://tickets.metabrainz.org/browse/MBS-6344

reosarevok:

Hi!

I was wondering what to do with tickets that ask to display last-active-time for an editor

[listenbrainz-server] atj opened pull request #1308 (master…startup-dump-fixes): Startup dump fixes https://github.com/metabrainz/listenbrainz-serv...

a) is this private data or could it be in, say, the subscriptions page and b) what would we even consider "last activity date"

I guess if we just take "date of last edit", for example, then it's public as it is and might be fine - if we also list "date they last tagged or rated", then not so much

We could show a "last edit/vote" which is semi-public data anyway?

personally I don't care about subscriptions, but going ot a n users accoutn ans seeing they where last active in, say 2009 will hlep with "shoudl i message thme with this edit"

or no"

bitmap: MBS-11417 (btw, not sure if it should be MBS or MBH)

MBS-11417: Investigate website performance after 2021/02/26 event https://tickets.metabrainz.org/browse/MBS-11417

i agree with last edit date being fine

I don’t think we should show when they last opened a page/renewed their session.

the first ticket is about showing it to editor/admin, there is no privacy concerns in this case, but it should not degrade performances

I agree that the info is useful - "last login" is effectively pointless since if everything goes well, you can go for months without that changing

yea that seesm. resuoure intensive for no great gain too

actually years :D

But showing last edit and/or vote date is probably fine, since that data could be found out anyway.

(I'm not sure why we even display it, given that)

ruaok: I'd like your call on this re: what's ok to display

And yeah, for last refreshed session date, that should be fine to show to user admins, I guess. (Or something less invasive like what the ticket actually suggest.)

this is not a presence network, just link to your twitter status or favorite social network from your MB profile if you want that.

date of last edit seems sane.

yvanzo: I assume we *want* to give people some idea of when the user was last active since we display last login date

It's just mostly useless

(wait, we display those for everyone, right? Or is it an account admin thing)

I think ruaok gave his answer? So let’s go with that? :)

reosarevok: we don't show last login date, but to admins.

Oh. Huh. TIL

Well, at the very least I'll make it so admins can say last edit date too then

Thans

*Thanks

Alright.

No additional topics have popped up, so this wraps up this meeting!

Thank you everyone for your time! Remember to stay safe and be kind to yourselves! ❤️

</BANG>

Thanks !

Thank you

reosarevok: https://github.com/metabrainz/musicbrainz-serve... paginated the /user/foo/tag/bar pages, right?

bitmap: yeah, are those one of the problem ones?

Thanks everyone!

alastairp: Shall we do the discussion today or tomorrow?

yes, this would be nice to get in to avoid those from timing out

_lucifer: There's some sentry issues you might want to take a look

bitmap: well I'm not going to complain about that :p

shivam-kapila: let's do it tomorrow. i have some comments on the doc as well.

But I have a "WIP"

I'm not sure the impact is as big as from area/release pages, but it's a problem for sure

Wonder wtf that's about

iliekcomputers: cool

was wondering the same :)

Oh, because the changes to editor messed it up and I needed to fix it

[listenbrainz-server] release v-2021-03-01.1 has been published by github-actions[bot]: https://github.com/metabrainz/listenbrainz-serv...

yvanzo: ^ can you take a look at this PR so we can resolve these tag page timeouts

... maybe it works now? I Dunno

_lucifer: https://sentry.metabrainz.org/metabrainz/listen...

I should test once I'm done with prod

shivam-kapila: tomorrow would be good. take a look at what I wrote and see if you can make a start

shivam-kapila: looks like that error is on the lastfm proxy, which I just took down to re-deploy

proxy.listenbrainz.org deployed with new consul version, and it's up. looks good

in config -> RABBITMQ_HOST = "10.2.2.42"

so it looks like the {{with}} + config option works, _lucifer !

:DD

I'm still at the office, so I'm going to go home now

_lucifer: how long are you awake for?

alastairp: 1. Cool. will try to 2. Okay okay (saw a bunch of those so I thought to inform)

alastairp: 30mins prob

_lucifer: ok, let's do the other containers tomorrow then

thanks for your time!

sure, let's complete this tommorrow!

reosarevok: any update coming to this WIP before reviewing that PR again?

yvanzo: IIRC that was all flow-related, but I will test and make sure once I'm done with releasing

Now building prod image

zas: do you know if postgres-floyd logs during this event are still available?

I was trying docker logs --since '2021-02-26T22:32:00' --until '2021-02-26T23:00:00' postgres-floyd but it just hangs

bitmap: try within nohup or screen and write to a file?

Updating prod

yeah, that's what I was doing

bitmap: yes, the log file weights 169Gb ... so

but it parses json ...

I'd run docker logs prefixed with nice for this, and wait for it to process

better output to a file btw

can I run the file through grep so I don't have to parse the json here? not sure where it's stored

/var/lib/docker/containers/1c4f6f8ab8cd5e52250b6451dded2b473e67cff6e70b48b0374ac2ba9817af03/1c4f6f8ab8cd5e52250b6451dded2b473e67cff6e70b48b0374ac2ba9817af03-json.log

thanks!

off for diner, bb later

yvanzo, bitmap: AFAICT all works in that branch. I think the WIP was probably because I meant to ask you two (esp. bitmap who wrote the changed code) whether this was the right and safe way of doing it

With the new changes to editor data