To implement this pause feature, what if we add a new function in listenbrainz/db/user.py called pause, where we move all the user data using user_id as primary key into another table called paused_users data where the columns are the aggregated columns of the data we are deleting. when the user tries to log in, we check if their id is present in paused table and render them a page which says their id is paused and if the user is
To implement this pause feature, what if we add a new function in listenbrainz/db/user.py called pause, where we move all the user data using user\_id as primary key into another table called paused\_users data where the columns are the aggregated columns of the data we are deleting. when the user tries to log in, we check if their id is present in paused table and render them a page which says their id is paused and if the user
is unbanned, we can restore their data. Does this approach seem correct for implementing it? monkey mayhem
BrainzBot
LB-1730: Allow admins to "pause" a user's account
lusciouslover has quit
lusciouslover joined the channel
julian45[m] joined the channel
julian45[m]
mostly for MeB core team, but: just in case there might be interest, i wanted to pass along this project i came across that could provide a matrix-based implementation of BrainzBot: https://matrix-org.github.io/matrix-hookshot/la...
of course, if BrainzBot is working fine, no inherent reason to move off it, just wanted to mention that this is out there
s/BrainzBot/BrainzGit and BrainzBot/g
lusciouslover has quit
lusciouslover joined the channel
petitminion joined the channel
lusciouslover has quit
lusciouslover joined the channel
tuxpaint has quit
tuxpaint joined the channel
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
petitminion has quit
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
MyNetAz joined the channel
Sophist-UK has quit
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
Kladky joined the channel
d4rk-ph0enix has quit
akshaaatt[m] has quit
d4rk-ph0enix joined the channel
d4rk-ph0enix has quit
d4rk-ph0enix joined the channel
mayhem[m]
<fettuccinae[m]> "https://tickets.metabrainz.org/..." <- it would be much simpler to put a flag "paused" into the user settings (and obviously only let admins change that) and then have the listens importer check the flag for that user. and if it is set, reject the listen.
BrainzGit
[bookbrainz-site] 14andrewsu31098 opened pull request #1147 (03master…docs/update-deprecated-jsdoclink): docs: replaced deprecated jsdoc link leading to spam site with updated jsdoc homepage link. https://github.com/metabrainz/bookbrainz-site/p...
<mayhem[m]> "it would be much simpler to..." <- Hmm. Should the listens be rejected entirely? I was more thinking we'd keep them, but not display any of it on the site
I mean, I guess in some cases the listens might be entirely bogus anyway, but someone might get paused for something else than bad listens, right?
Being a dick or whatever
mayhem[m]
reject, for sure. cleaning that mess up is a PITA.
especially if we are talking about 10s of thousands of listens
reosarevok[m]
Wouldn't you still need to do that anyway with all the previous listens?
Anyway, I guess I'm not saying you should process them, more like store them for later rather than just dropping them entirely since that's lossy
But it might be that is not doable at all with the system you have
If so that's fine, but it just limits the feature from something that can be used just in case while we talk to the user to something that should only be used in egregious cases I guess
Better than not having anything, in any case, and maybe it can be extended later to "pause and reject" vs "pause and store" if we could implement it eventually, so
mayhem[m]
reosarevok[m]: we can always delete the account.
reosarevok[m]: lots more work.
reosarevok[m]
I mean, deleting the account would work even if you didn't reject the stuff :) but yeah
I meant more if they fix whatever is messed up you still have all the old data that was still messed up (there was someone reported for having a faulty client sending malformed xml titles fo rexample)
[bookbrainz-site] 14MonkeyDo merged pull request #1147 (03master…docs/update-deprecated-jsdoclink): docs: replaced deprecated jsdoc link leading to spam site with updated jsdoc homepage link. https://github.com/metabrainz/bookbrainz-site/p...
<julian45[m]> "mostly for MeB core team, but..." <- Hi julian45, it looks like it could partly replace some features of BrainzBots and BrainzGit.
BrainzGit is working fine and its upstream repository is actively maintained, but we don't follow it and it relies on IRC. Not urgent, but good to replace.
BrainzBots are unmaintained and use dependencies with known vulnerabilities. See OTHER-422 for instance.
yvanzo: I saw your comment in the Solr metrics PR about using `ps auxww | grep Djetty.host=localhost` for the healthcheck too. I was a bit confused at first, but I think I understand now that the issue is that the start-local-solrcloud script is temporarily starting Solr to listen on localhost:8983 rather than *:8983 (missed that at first)
yvanzo[m]
reosarevok: Any update (even blocking issue) on your side?
bitmap: exactly
bitmap: There might (certainly is) a neater way to check for process arguments, but that seems to work at least.
bitmap[m]
got it, perhaps using lsof or netstat to find which interface it's listening on would be reliable too?
reosarevok[m]
Nothing other than it'd be good to have a clear decision on how often to check sql
yvanzo[m]
bitmap: yes, anything that is easy to implement reliably would do :)
reosarevok[m]
So we can merge that pr
You think 5 min is too much, how much do you feel makes sense?
1 min? Less?
bitmap[m]
cool, I can look into using lsof since it's available in the container, otherwise I'll fall back to the ps trick
yvanzo[m]
(I just used ps because I was in an interactive shell really.)
vardhan has quit
bitmap: Any suggestion for the interval otherwise?
I’m under the impression that these requests have a very low cost and can be made much more frequently.
bitmap[m]
hmm, I think 5m seemed ok since if you have to replay tons of packets, you should probably start by importing a more recent full dump first. and you can still check replication logs for immediate feedback
yvanzo[m]
So merging as-is?
bitmap[m]
the requests do have a very low cost, though I was more thinking about whether they are storing too many unnecessary data points in prometheus
I'd be fine with merging as-is
yvanzo[m]
I just thought that it would be more convenient to have everything in the same dashboard than having to check replication logs, but we will see when using it.
reosarevok your answer ^ please still make the checks about service dependencies (especially when starting with no volumes)
(after merging)
bitmap[m]
I guess ideally these data points would be fed into prometheus by the replication script itself & we could poll hourly as a fail-safe
minimal joined the channel
yvanzo[m]
bitmap: Do we need RabbitMQ metrics? Or should we instrument triggers instead so it can work with both rabbitmq and dbmirror2 impl?
(It wouldn’t cover retry queues though.)
Probably better instrument SIR then so it can check any message queue, and also its own activity.
bitmap[m]
right, I think adding the metrics to sir (i.e. when it processes the messages) would be best for us
although it is probably trivial to add a rabbitmq dashboard in the meantime
