ruaok: this is definitely in the wrong place anyway, so should be an easy win
2021-03-24 08336, 2021
alastairp
_lucifer: yes! exactly
2021-03-24 08349, 2021
prabal_ has quit
2021-03-24 08308, 2021
ruaok
oh good, that would drastically improve my life.
2021-03-24 08305, 2021
alastairp
we just had a good talk about questioning a bunch of our existing assumptions with our build/test/deploy stacks, which I think was really useful
2021-03-24 08305, 2021
ruaok
indeed. and one of the thoughts I put on the table: if our lives could be made easier by paying some money to free up our own resources, that should be considered as a possibility.
2021-03-24 08340, 2021
ruaok
its my discover weekly, which incidentally is listenable again. I turned of "keep playing music after this album finishes" and thus am picking much more of what i want to listen to. in turn DW works well -- at least this week.
2021-03-24 08341, 2021
BrainzGit
[listenbrainz-server] amCap1712 opened pull request #1356 (master…validate-auth): LB-793: validate-token endpoint takes token as an argument instead of header https://github.com/metabrainz/listenbrainz-server…
2021-03-24 08338, 2021
outsidecontext
just noting that I'm pretty happy with Github actions for Picard. But requirements are likely a bit different, so not necessarily comparable
2021-03-24 08346, 2021
outsidecontext
should there be a certain limit of free runtime minutes per organization we are probably already using a bit of that. But I'm not aware there is such a limit :D
2021-03-24 08340, 2021
alastairp
thanks outsidecontext
2021-03-24 08338, 2021
alastairp
yeah, I use it on another (closed) project. a free plan has 2000 minutes/month, and the lowest level paid plan has 3000 I think (and I believe our MeB non-profit plan is approx equal to this one). but as _lucifer said, theoretically it's free for open source projects, so we should try it
2021-03-24 08342, 2021
_lucifer
alastairp, should we proceed with the lb releases?
2021-03-24 08352, 2021
alastairp
_lucifer: I'm just doing that right now
2021-03-24 08355, 2021
alastairp
as we speak
2021-03-24 08300, 2021
_lucifer
nice :D
2021-03-24 08320, 2021
_lucifer
let me know if i can assist in some way
2021-03-24 08332, 2021
ruaok
yeah, same here.
2021-03-24 08344, 2021
alastairp
cron, timescale, web restarted
2021-03-24 08325, 2021
alastairp
websockets, api compat, spark reader, labs api restarted
2021-03-24 08348, 2021
alastairp
_lucifer: spark reader makes no noise when it starts up. is this something that we improved in a PR?
2021-03-24 08339, 2021
ruaok
I thought I did, but I may not have committed that.
2021-03-24 08311, 2021
_lucifer
yes, i added a log statement before it attempts to connect to rabbitmq
but I don't see this log message: `current_app.logger.info('Spark consumer started!')`
2021-03-24 08307, 2021
alastairp
which was already there
2021-03-24 08335, 2021
_lucifer
is `basic_qos` blocking call?
2021-03-24 08328, 2021
alastairp
the process is running in the container (I can see it with ps)
2021-03-24 08333, 2021
alastairp
it might just be an issue with logging
2021-03-24 08307, 2021
ruaok
alastairp: it seems that a good pattern is to always include a top level `try: except Exception` block as the first thing in a thread's run() method.
2021-03-24 08321, 2021
alastairp
ruaok: we've moved an apt-get install in the Dockerfile further up, so changes to crontab won't cause apt-get install node to happen again and again
2021-03-24 08336, 2021
ruaok
great. is that in master?
2021-03-24 08338, 2021
alastairp
you had one of them swallowing your exceptions?
2021-03-24 08346, 2021
alastairp
I guess Mr_Monkey is opening a PR
2021-03-24 08348, 2021
ruaok
multiple levels of swallowing.
2021-03-24 08316, 2021
ruaok
in the future I will just put those in as a habit to save myself this frustration.
2021-03-24 08344, 2021
alastairp
we've still got another issue, where according to dockerfile best-practises, items that change frequently should happen later in the file
2021-03-24 08303, 2021
alastairp
so we have 1) runit scripts, 2) crontabs, 3) npm install and npm build
2021-03-24 08322, 2021
ruaok
and one single execution chain. :(
2021-03-24 08325, 2021
alastairp
to us, logic dictates that js code changes most frequently, and so should be put last
2021-03-24 08328, 2021
alastairp
yeah
2021-03-24 08350, 2021
ruaok
but do the install of js code change frequently? not so much.
2021-03-24 08353, 2021
alastairp
we just came to the realisation that while all services use the same image, only web needs the js assets (most other images need the python assets)
2021-03-24 08354, 2021
ruaok
does
2021-03-24 08304, 2021
ruaok nods
2021-03-24 08341, 2021
alastairp
well, it means that if you have to do a dev cycle of changing crontab/rebuild, the docker image cache will be invalidated and you'll have to rebuild the js files
2021-03-24 08353, 2021
alastairp
remember that js installation is two steps - installation of dependencies, and then compilation of code
2021-03-24 08306, 2021
ruaok
should we separate those two steps?
2021-03-24 08312, 2021
ruaok
installation first, code last?
2021-03-24 08322, 2021
alastairp
we were considering that
2021-03-24 08354, 2021
alastairp
so we could do 1) runit scripts, 2) js dependencies, 3) crontabs, 4) build js files
2021-03-24 08316, 2021
alastairp
it kind of feels like we're hyper-optimising your specific use-case though, and we're not sure if this happens frequently enough that it's worth the effort?
2021-03-24 08321, 2021
alastairp
not sure, it's difficult to gauge
2021-03-24 08354, 2021
ruaok
I dont think the order of 1-3 is all that important, but having 4 last makes sense to me.
2021-03-24 08326, 2021
ruaok
that should not be that much work, right?
2021-03-24 08339, 2021
alastairp
agreed, having 4 last makes sense to me, and this is easy to do
2021-03-24 08357, 2021
ruaok
lets go for that and if it still is slow, we'll take another look.
ruaok: ^ fyi, that's all I have to run our own docker registry server
2021-03-24 08343, 2021
alastairp
or in non-docker-compose syntax: `docker run registry -v whatever -p whatever`
2021-03-24 08313, 2021
ruaok
zas: do you remember why we chose to use docker hub instead of our own registry?
2021-03-24 08330, 2021
ruaok
sometimes pushing to docker hub is freaking slooooooow.
2021-03-24 08314, 2021
zas
yes, it is. I guess we didn't really made a choice, I tried to set up our own registry at some point for caching purpose. You can build locally and push to docker hub, I usually use autobuilds (I tag the git repo, it builds), but in all cases there are delays
2021-03-24 08319, 2021
ruaok
I think it would be nice to have our own, but it would gobs of diskspace, I think.
2021-03-24 08324, 2021
zas
now, setting up our own registry is likely possible, but as usual, it implies resources, redundancy, backups, upgrades (well, you know that), that's the usual reason we use external resources ;)
2021-03-24 08339, 2021
ruaok
yeah.
2021-03-24 08350, 2021
ruaok
github has a container registry too, no?
2021-03-24 08358, 2021
zas
I think so
2021-03-24 08318, 2021
ruaok
well, its something we should consider once we get past some of the infrastructure improvements we're currently making.
