[listenbrainz-android] 14dependabot[bot] opened pull request #172 (03main…dependabot/gradle/io.sentry.android.gradle-3.8.0): Bump io.sentry.android.gradle from 3.7.0 to 3.8.0 https://github.com/metabrainz/listenbrainz-andr...
So that stuff doesn’t get lost across timelines/metabrainz messages
zas
reosarevok: so, if you have 2 containers C1 & C2 running 'image:tag' with id 1, once you retrieved 'image:tag' with id 2 and used it for C1, C2 would have his image listed as id 1 rather than its name, so basically search by name isn't reliable. And that's perhaps what is happened with your script.
lucifer the webview works amazing but lags a lot for me
It basically took 5-10secs to load every single screen and then around 10secs to redirect
Zhele joined the channel
Zhele has quit
Zhele joined the channel
lucifer
akshaaatt: yeah, i had marked it as draft so that you could take over and make any changes you want later. feel free.
yvanzo
O’Moin
lucifer
akshaaatt: it works quite fast for me even in the emulator.
i am not sure why it lags in your case.
Zhele has quit
Zhele joined the channel
q3lont joined the channel
rozlav joined the channel
zas
all containers were stopped on kiki & herb
reosarevok
zas: so is the point that while we usually had one container per server for a service, now we have several or?
moin yvanzo :) Seems we need to update the update script
zas
reosarevok: technically you can have multiple containers for a service, even on the same node. It is just about them to not conflict (different ports and names).
reosarevok
Sure, it's just we have never had this issue before the update, so I was wondering what changed :)
(that we'd now have a C1 and a C2 to conflict)
yvanzo
reosarevok: containers update script?
reosarevok
Yeah. It broke when trying to update beta because it was expecting to get back the container name but got the id instead
the script compares a container name with a container id
reosarevok
But that used to be both container names
zas said that: "if you have 2 containers C1 & C2 running 'image:tag' with id 1, once you retrieved 'image:tag' with id 2 and used it for C1, C2 would have his image listed as id 1 rather than its name, so basically search by name isn't reliable. And that's perhaps what is happened with your script."
yvanzo
We don't have 2 containers running the same image tag on paco.
I looked in more details for BB, the container looks fine (tried restarting it too) but requests don't seem to hit it.
Help please :)
aren't working*
yvanzo
There are new beta images atm but the containers are still running the old image, no longer matching the image beta tag, so it’s expected that the image for the container is listed with an id instead.
Thanks!
Something to start with :)
reosarevok
Yeah, the image was generated, just not updated
But that's the same process we've always followed and this used to work
Which makes me assume the change must be in the new setup from yesterday
But I'm keen on aligning with MB, no reason to be off by one
reosarevok
Oh, ok, so just starting from 1 and there's no "default" no privs flag
I mean, we don't have a 0 flag :)
It's just 0 if there's nothing we would call a priv
monkey
I guess 1 is the default no special privs
reosarevok
(so, they just use the site normally)
monkey
That's how I read 'ACCESS_THE_ENTITY'
reosarevok
Yeah. I don't think that's wrong either, as long as you document it somewhere
yvanzo
reosarevok: I just ran the script again and it worked fine.
monkey
= read
reosarevok
yvanzo: huh, ok :) Maybe I should have just retried :D
"retry until it works" is not the most ideal approach, but hey, if it works for our selenium tests 🤣
yvanzo
atj, zas: Might it be that docker-server-configs working copy at paco was not up-to-date when reosarevok tried to update beta?
monkey
zas thanks for checking. Mystery. I swear test.LB and test.BB were working yesterday after the consul migration, I checked them
reosarevok
monkey: do you have a constants file? I'd put the constants in that file already if so, so that everyone has a clear view of the meanings from the get go :)
yvanzo
Since the script that failed is the one that zas patched in the PR. The error message was possibly about the consul container being stopped.
zas
monkey: I keep searching, the problem is real, that's just not that
monkey
Yep
reosarevok
yvanzo: ok, I guess I'll continue with a prod release then for now and see if it all works, unless you have anything against it? :)
Well, after a brief check that beta works :)
monkey
reosarevok: Good call. We don't have a central constants file yet but there's a good place for it