#metabrainz

I keep getting into situations where someone gets reported that would just require a quick email to defuse / improve

But I cannot write because it's a temporary mail, which also explains why they ignore edit notes, etc

hm

do it.

So I end up having to block the users, and everyone else is posting into the void

yea i mena, yea

I think it was tykling (IRC) who mentioned there are some good lists of temporary providers that could be used for that, any chance you can point me at those? :)

Since it seems mostly people are fine with the idea

Temp emails users are rarely good news.

IMO

very anti-community

I support them for some purposes, but not MeB accounts

I mean, there's a genuine case of the user who comes, wants to check what the hell but is scared of getting spammed / scammed. But we don't do that, so... I think it's fair

that

Creating a free email account somewhere from a no-temp-email-provider is very easy and quick, there's always that for those who insist.

Ok, I'm not hearing any reasons why this is a terrible idea, so no rush with it but I'll put it on my list

Next!

there's more?

docker-server-configs (@mayhem)

hiya!

But wait, there's more!

so, the LB team has been pretty poor about updating the docker configs before updating containers.

which makes it hard to find out which image of a container should be running. I even found an image running that had no reference in docker-server-configs at all.

this is a recipe for disaster. or disaster during disaster recovery.

I dont think we should really attempt to solve the problem here and now, but I would love to see if people have thought about this and how we could improve it.

LB uses github for building docker images, so there is likely a way that we could automate this, but...

it smacks of effort.

zas: or atj : have you given this any thought?

I'm pretty sure we also forget sometimes in MB, it's not always obvious :)

(but our stuff changes relatively rarely so we haven't gotten into significant trouble yet...that we know)

ours are constantly changing, so its a real issue for us.

well, if no one has any thoughts on this, I will start thinking about what we could do to automate this process.

Dumb question sorry, is this a technical question or more of a process question?

a technical process question. :)

perhaps I should've asked this question in a smaller group -- it doesn't concern the whole team.

the workflow that automatically builds a docker image on release publish, in LB repo, can be set up to hit a webhook somewhere, for example\

yeah, but where do we store that info?

anyways, seems like that now is not the right time. let me think about it and then I'll pick it up again with zas/atj.

back to you reosarevok

Thanks!

Those are all the topics, but I'm going back for a second to the emails one

I just remember we want to move to MeB accounts soon anyway

Would it make sense to just have this be a baked-in requirement for the new MeB account system?

Or is it far enough that I should implement it in MB first?

the emails.. oh the no -temp email

i mena it's fine ot implement that right now i think

unless it's HUGE work

and will require hax later

You’re dealing with the fallout reo (new spam/sockpuppet accounts being created) so you might be the best person to decide?

reosarevok[m]: probably close enough to do in MeB.

if it's easy to do I say just od it asap

then again, it doesn't sound like a BIG task.

Who'd work on that on MeB, lucifer?

I could coordinate with him so we implement it in a way that works for both cases so we don't reinvent the stuff soon later

time spent implementing the block vs time spent moderating temp email account sockpuppets

I made MBS-13835 as a MBS ticket for now, but whoever would look into this for MeB, talk to me and we can look at it for a moment at some point :)

MBS-13835: Block creating accounts with temporary emails https://tickets.metabrainz.org/browse/MBS-13835

then again it's done once and thne temp-email sockpuuppets go away

Enough for now, I think!

it would likely be ansh or lucifer. likely both.

Ok, perfect. I'll have a talk with them during this week and look into it

That's it for today, I think, since I don't think late reviews are incoming

Thanks everyone!

More in a week!

</BANG>

Thanks reo!

mayhem: https://medium.com/hostspaceng/triggering-workf...

Get the release workflow on LB commit or create a PR in docker-server-configs?

Thanks all! Always a pleasure

yea, I see that this could work. but I am hesitant to fully automate this. sounds like an invitation for trouble.

Hey ansh, shall I feedback on test now, or you still working on it?

*prepare feedback, won’t be done now

monkey: I think a command line app that does the update might be a safer option.

meb-update.py listenbrainz-web-prod v-2024-11-22.0

aerozol: hellooooo! The flairs on LB are about ready to be released. If you want to do a blog post etc. about it we can wait for the final merge to coordinate the release

as an explicit action, rather than an automated action.

people can still forget, but its muuuuch easier than the current process.

woohoo! Keen. I would love to grab some screenshots, are flairs up anywhere?

erhm i'm still not showing on that page tho

anyways, off to catch some noms now.

aerozol: not at the moment but I can put it up in the coming days. Cna also take screenshots if you'd like

Sorry to be cross-talking like this, but mayhem fyi I think all I need to setup those accounts is the login and pw for whatever email we are using for those socials. I think twitter@meb which is pretty funny and we should keep. If there’s no further authentication I can get cracking once I have the login 🤞

That would be great thanks monkey

A gif would be best, I'll see what I can do

ooh

Good idea

aerozol: what exactly do you need from me?

I think I just need the login/pw of the twitter email, then I can make new accounts today

If there’s further authentication needed to login I might ping you again after your noms

<BobSwift[m]> "I'm guessing that if the merge..." <- the images are still available under the old mbid at the archive (`/details/mbid-$old_mbid` should work). we also have the failed "copy-image" events stored which can be requeued if the archive ever fixes the issue (though we probably wouldn't be able to mass-requeue them, as some have likely been copied over manually at this point)

Okay, but sounds like finding them requires some extra work by the users (even it it's not much). That was the point I was trying to make.

I guess I’m hoping that IA fixes this soon and then we can put together a little info pack/message for those who want to help move images? With links etc (or how to easily generate the links)

Or do you think we should be letting users know now bitmap (that the images aren’t being moved)

yeah, I was wondering if we should set a global banner message for now, and perhaps add a warning the merge page in case the issue persists. do you have another idea?

A global banner sounds perfect for now. Can’t miss it, and users can hide it

Might be good to include what you expect/want users to do, e.g. migrate the images manually

<BobSwift[m]> "Okay, but sounds like finding..." <- you're right, it's not obvious at all how to get the old MBID either (it's not available from the merge edit once it passes). you have to go in the edit history and view the raw edit data of the "add release" edit (for the removed release)

<aerozol[m]> "Might be good to include what..." <- how does this sound: "Images are currently not being copied over after event or release merges. For now, please make sure to upload any images that should be kept to the merge target beforehand."

Looks good!

[bookbrainz-site] 14dependabot[bot] opened pull request #1141 (03master…dependabot/npm_and_yarn/elastic/elasticsearch-8.16.2): chore(deps): bump @elastic/elasticsearch from 5.6.22 to 8.16.2 https://github.com/metabrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] closed pull request #1139 (03master…dependabot/npm_and_yarn/elastic/elasticsearch-8.16.1): chore(deps): bump @elastic/elasticsearch from 5.6.22 to 8.16.1 https://github.com/metabrainz/bookbrainz-site/p...

mayhem: sorry, I was cooking, and missed your question. And to be honest I don't understand what's the exact issue. The normal and safe process should be: build the image, update docker-server-configs, and deploy. But sometimes that's not very practical. How are your images built for LB right now?

Via GitHub. And everyone skips the docker server configs step

If people don't follow the process, the process is broken.

Well, if we don't have the correct version of an image in docker-server-configs, it could be an issue if we need to redeploy on another server. It happened to me to forget to commit changes regarding image versions or the like. But to me that's clearly a process issue.

For example, for picard-website, the image is built via a hook, tagged version, then the scripts should be updated to use this version. Though I usually deploy manually for testing, and only update scripts afterwards, I guess you do more or less the same.

With current setup, I don't see much solution to this, but being rigorous. On the long term, we should move to some container orchestration system and stop to do manual deployment.

Hey mayhem do you want to create the Bluesky accounts the “proper” way, using our domains, like you did with MeB and LB?

If so is it worth me creating accounts the pleb way/will it migrate stuff over?

<aerozol[m]> "Hey mayhem do you want to create..." <- Yes. But that can be done after the fact

Cool, I'll truck on

zas: hey, when you have time can you help with updating the CAA index queue alert on https://stats.metabrainz.org/d/000000075/alerts... ? previously it came from rabbitmq, now it needs to be queried from postgres