<VITAS[m]>
i should comapre current and head myself
<VITAS[m]>
so ansible knows what kind of status we have
<DasSkelett[m]>
If there is no db at all, I guess alembic will throw an error. If there is an empty one which has just been created it will be current head so the command will return 0.
<DasSkelett[m]>
Yes. Theoretically Alembic can handle branching and merging again, so that there would be multiple heads. However I try to avoid that for SD since it complicates things unnecessarily. So de facto, it will always return the latest revision
<DasSkelett[m]>
Also it will only show the latest head if you have the latest code checked out. In the output you posted it shows `77f76102f99c` as latest head, which it is on master, but not beta/alpha. So you have to make sure to pull the code before.
<VITAS[m]>
i will
<VITAS[m]>
its only to find out if prod db has migrations ive to run
<VITAS[m]>
i prepare everything on the staging host using a temp/dummy db
<DasSkelett[m]>
You should also use the downtime to update ATS, got a security notification yesterday ^^ Something with DoS with malformed HTTP/2 headers.
<VITAS[m]>
and if there are migrations ive to run them on the real db too
<VITAS[m]>
yes
<VITAS[m]>
i plan to do quite a lot on the server end
<VITAS[m]>
e.g. migrate to ubuntu 20
<VITAS[m]>
move storage
<VITAS[m]>
swap prod host for the new a&b hosts
<VITAS[m]>
and so on
<VITAS[m]>
will you be ready with some code you want to deploy?
<DasSkelett[m]>
We are going to merge beta to master, aren't we?
<VITAS[m]>
thats your and HebaruSan s decission
<VITAS[m]>
my original idea was to do that
<DasSkelett[m]>
We both decided yes, I'm pretty sure.
<VITAS[m]>
but you have more insight and are the ones doing most of the coding
<VITAS[m]>
ill deploy whatever is in master at that point
<VITAS[m]>
old and new code :)
<DasSkelett[m]>
As of right now there's no new undeployed code on master, would be a lame update π
<VITAS[m]>
im throwing away the current prod host
<VITAS[m]>
so it isnt
<VITAS[m]>
:D
<VITAS[m]>
easier to migrate to ubuntu 20 by having a new container than updating the old
<DasSkelett[m]>
I hate celery.
<DasSkelett[m]>
Both the one to eat and the software.
<VITAS[m]>
sounds healthy :P
<VITAS[m]>
i like the eating one
<VITAS[m]>
in small chunks in geiΓburger marsch and bolognese sauce
<VITAS[m]>
but its ok to hate what email has become
<VITAS[m]>
i dont know if celery is to blame
<VITAS[m]>
its all the crap added to email because of the overwhelming amount of crap mail floating arround
<VITAS[m]>
and the jobcenter tells me: just mail me your passport copy, bank statements,....
<VITAS[m]>
and im replying "could you in return send me a postcard with your banking pin?"
<DasSkelett[m]>
There's a ton of these when restarting spacedock.target. So it looks like celery gets stuck sending the emails...
<DasSkelett[m]>
`spacedock-celery.service: Found left-over process XXXX (celery) in control group while starting unit. Ignoring. This usually indicates unclean termination of a previous run, or service implementation deficiencies.`
<VITAS[m]>
Darklight!
<VITAS[m]>
could be that we simply close it
<VITAS[m]>
when we did it by script we jsut termianted the screen
<DasSkelett[m]>
Postfix also fails to start, but that shouldn't have an effect on the emails from SD/celery.
<VITAS[m]>
and i know there are mails that cant be send and are in the sys for ages
<VITAS[m]>
postfix on sd shouldnt be needed?
<VITAS[m]>
it sends stuff directly doesnt it?
<DasSkelett[m]>
Directly to the gateway, yes.
<VITAS[m]>
hello to you
TimeFaker[m] has joined #spacedock
<TimeFaker[m]>
hello
<TimeFaker[m]>
this is dmp right?
<VITAS[m]>
no but you can ask that too
<DasSkelett[m]>
Not quite, although the user base overlaps a lot.
<DasSkelett[m]>
Not quite, although the discord user base overlaps a lot.
<TimeFaker[m]>
oh okay
<TimeFaker[m]>
so here is my question
<VITAS[m]>
DasSkelett: what does alembic heads exactly show?
<TimeFaker[m]>
how to fix the reputation loss in ksp dmp career mode
<VITAS[m]>
you cant i guess
<VITAS[m]>
Darklight usualy suggests lmp
<VITAS[m]>
for career
<TimeFaker[m]>
oh well thats a bummer
<TimeFaker[m]>
oh really well i will check it
<VITAS[m]>
its the price of syncing games by spawning and removing vessels
<VITAS[m]>
DasSkelett: does heads check the currently used db?
<DasSkelett[m]>
<span class="d-mention d-user">VITAS</span> it shows all the current revision heads (i.e. the latest revisions). In our case that's max. one.
<DasSkelett[m]>
It's <span class="d-mention d-user">HebaruSan</span>'s type hints PR, that changed the behaviour of `send_mail()`. It now returns when `smtp-user` and `smtp-password` are not set, which they aren't in alpha+beta(+prod I think), because they aren't needed.
<DasSkelett[m]>
That also explains why it worked on my local dev system all the time, because I have them set to log into my mailserver.
<VITAS[m]>
ah
<DasSkelett[m]>
<span class="d-mention d-user">VITAS</span> your mail gateway doesn't use TLS to connect to other mail servers.
<DasSkelett[m]>
<span class="d-mention d-user">VITAS</span> your mail gateway doesn't use TLS when connecting to other mail servers.
<VITAS[m]>
it doesnt?
<VITAS[m]>
i think it does
<DasSkelett[m]>
Nope, my mail server got all connection attempts via ESMTP, not ESMTPS. Google also displays a "not encrypted" warning.
<VITAS[m]>
maybe if the mail doesnt route via the mailserver
<VITAS[m]>
but directly
<VITAS[m]>
ill check when ive time
<DasSkelett[m]>
So looking at the ConfigParser documentation, you _have_ to specify a section if you want to look up an option.
<DasSkelett[m]>
But our `config.py` abstracts them away completely, by providing generic lookup methods that always look up the `[dev]` section under the hood.
<DasSkelett[m]>
So if we want to split it into multipe sections we would always have to pass the section name to `_cfg*()` whenever we want to read an option, and I don't think that's worth it.
<VITAS[m]>
k
TimeFaker[m] has quit [Quit: Client limit exceeded: 6]
HebaruSan[m] has joined #spacedock
<HebaruSan[m]>
I think as a general rule, "What code is production SD running?" should be the same as "What's shown on the master branch on GitHub"
<HebaruSan[m]>
So merging stuff long before the update would be confusing
<HebaruSan[m]>
Now how should we get #299 into beta? Another full alpha merge?
<DasSkelett[m]>
> Well then let's hope we don't find any bug where we would have to somehow merge a fix to beta, without cherry-picking and without merging anything else to beta.
<HebaruSan[m]>
Yes I know π
<HebaruSan[m]>
I kind of want to do a full merge
<HebaruSan[m]>
Get the speed-up stuff into prod
<HebaruSan[m]>
I've been doing kind of a lot of dev off of alpha and had no problems with that stuff
<HebaruSan[m]>
And the only other changes are admin page usability (users not affected)
<DasSkelett[m]>
I agree, everything that's currently in alpha is okay to be merged to beta. A full merge would be okay for me, but I will leave the decision to you.
<DasSkelett[m]>
To safe us from a more hairy situation if we find another last-minute bug, I'll stop approving any new PRs from now on until we have deployed to production, with the intent that they don't get merged to alpha until then.
<VITAS[m]>
(missing the actual ats restart/cache flush and updating of stage after the switch)
<HebaruSan[m]>
Do you have backups of that document in case a random IRC user decides to delete it or replace it with advertisements for pirated movie web sites?
<VITAS[m]>
theo one i posted is the shell output
<VITAS[m]>
and yes you have versions you can skip back to in the pad
<HebaruSan[m]>
OK, bood
<HebaruSan[m]>
OK, good
<VITAS[m]>
i do that all the time when someone decides to edit the dmp help pad with google translate
<VITAS[m]>
i should make it a bit more clear what ansible is doing and why
<DasSkelett[m]>
<span class="d-mention d-user">HebaruSan</span> I think that's fine. All the queried options are set in alpha and likely in production too. All but `site-name` are required for `SMTPHandler` to actually work, too.
<DasSkelett[m]>
Both ifs could be combined for cleaner code, but that's not a problem.
<VITAS[m]>
ill investigate the tls thing. it might be gone if we use a normal mail acc ont he mails erver but there where reasons i didnt do that
<VITAS[m]>
ai also checked ats updates. its runnign the newest ver ubuntu 18 offers
<VITAS[m]>
and thats one quite a bit behind current stable
<VITAS[m]>
ill check if ubuntu 20 has something better
<VITAS[m]>
quite a bit of work (and change) on my plate for the next update
<HebaruSan[m]>
You think that's old, up until a day or two a minor part of CKAN's infrastructure was still running Ubuntu 14.04
<DasSkelett[m]>
Just looking at the exact same page.
<VITAS[m]>
:)
<VITAS[m]>
the solution is: setting up the second container with temp ip. copy over the config
<VITAS[m]>
check if stuff is screaming
<VITAS[m]>
if not swap ips when we have a window
<VITAS[m]>
delete the old container
<VITAS[m]>
the same ill do to sd1/ prod
<VITAS[m]>
(and will have to do to the rest of my crap like mailserver....fun times)
<VITAS[m]>
can you freeze master by the end of tomorrow (and not add anything on the 30th)?
<HebaruSan[m]>
<span class="d-mention d-user">DasSkelett</span> , help getting beta running, getting 500s and ModuleNotFoundError: No module named 'packaging'
<HebaruSan[m]>
(when trying to run ./spacedock database migrate)
<HebaruSan[m]>
Where did this `bin` come from? It's not in git?
<DasSkelett[m]>
No, it's a virtual env
<HebaruSan[m]>
Yikes, more containerism
<HebaruSan[m]>
OK, I'll give that a try. Sudo as www-data first or no?
<DasSkelett[m]>
It's created like this: `virtualenv -p python3 --no-site-packages .`
<DasSkelett[m]>
Avoids installing all packages globally.
<DasSkelett[m]>
It's created like this: `virtualenv -p python3 --no-site-packages .` (don't run that command now)
<DasSkelett[m]>
Avoids installing all packages globally.
<DasSkelett[m]>
shouldn't be needed, should work with your user.
<DasSkelett[m]>
Actually, not sure. Try it π
<HebaruSan[m]>
ModuleNotFoundError: No module named 'packaging'
<DasSkelett[m]>
Ah come on
<HebaruSan[m]>
Dear python3, please just download and install when we use the import command, sincerely, everyone
<DasSkelett[m]>
Did you really run `python3 spacedock database migrate`? `./spacedock database migrate` won't work since it uses the dist-installed python3 executable. (We should change that)
<HebaruSan[m]>
Oh. No, I ran ./spacedock, because its first line runs python3 and the other command wouldn't tab-complete
<HebaruSan[m]>
OK, that worked
<HebaruSan[m]>
But that's very bizarre on Unix
<HebaruSan[m]>
`/usr/bin/whatever myscript` should be the same as `./myscript` if `myscript` starts with `#!/usr/bin/whatever`
<HebaruSan[m]>
Kind of the whole point of the `#!` syntax
<DasSkelett[m]>
But it's not `/usr/bin/whatever myscript`, but `./bin/whatever myscript`.
<HebaruSan[m]>
Alright, I'm going to merge beta -> master today or tomorrow. Ideally this would be more integrated into the upgrade process so GitHub master would always match prod, but a day or two difference isn't that bad.
DasSkelett[m] has quit [Quit: Client limit exceeded: 6]
<VITAS[m]>
we can do that automated once i got my system working
<HebaruSan[m]>
I know you meant partying but my mind went to β
<VITAS[m]>
no pray
<HebaruSan[m]>
Oh!
<VITAS[m]>
π
<HebaruSan[m]>
Why not all three
<HebaruSan[m]>
partying, parrying, praying
<HebaruSan[m]>
Sounds like a SpaceDock upgrade to me
<VITAS[m]>
in a different order yes
<VITAS[m]>
βπ party
<HebaruSan[m]>
Gotta pray first so Jesus takes the wheel
<HebaruSan[m]>
That song title still makes me laugh, imagining the saviour from the first century AD teleported to the present and just driving around in his robes
Darklight[m] has joined #spacedock
<Darklight[m]>
I should have probably shown my test deploy script
<Darklight[m]>
I have to get ready for work though
<VITAS[m]>
have fun?
<VITAS[m]>
yes im interested in every bit of automation we can get (especialy testing the crap out of every stage)
<VITAS[m]>
im now installing a replacement ats i can swap to
<HebaruSan[m]>
What is our point of no return for updating master? I.e., when is the last possible moment I can merge and still get stuff into the update?
<HebaruSan[m]>
In UTC, I guess, I'll convert π€¨
<VITAS[m]>
when i start updating sd
<VITAS[m]>
i will shout out before
<VITAS[m]>
the dc said they do things roughly between 800 and 16000 cet on the 30th
<VITAS[m]>
ill investigate tomorrow when exactly
<VITAS[m]>
i hope i can narrow it down
Darklight[m] has quit [Quit: Client limit exceeded: 6]
DasSkelett[m] has joined #spacedock
<DasSkelett[m]>
Hetzner is always so precise.
<VITAS[m]>
theres a lot new stuff im deploying so i want to be sure master isnt changing while im ripping out hosts and putting in new ones :)
<VITAS[m]>
yes DasSkelett i feel like they care less and less about customers running productive env
<HebaruSan[m]>
OK, I'll target a couple hours before that 0800 CET time for safety
<VITAS[m]>
if i get everything i plane din place we can do updates faster in the future
<VITAS[m]>
so we could do them more often if we want to
<DasSkelett[m]>
I guess VITAS means CEST, so UTC+2.
<VITAS[m]>
(i wouldnt do more than once a month)
<VITAS[m]>
Start: 30. Juni 2020 08:00:00 CEST
<VITAS[m]>
Ende: 30. Juni 2020 16:00:00 CEST (voraussichtlich)
<VITAS[m]>
FSN1-BX239
<VITAS[m]>
they say downtime of a few minutes
<VITAS[m]>
but not when in that timeframe
<VITAS[m]>
may i say: assholes
<VITAS[m]>
FSN1-BX1 bis FSN1-BX499
<VITAS[m]>
so that would put me in roughly the middle
HebaruSan[m] has quit [Quit: Client limit exceeded: 6]
<VITAS[m]>
my plan is to migrate as soon as possible in the window and then let the site run till it craps out and hope that the changes made to the way im mounting storage will bring it back automaticly
DasSkelett[m] has quit [Quit: Client limit exceeded: 6]
HebaruSan[m] has joined #spacedock
<HebaruSan[m]>
I will target 2020-06-30T04:00:00Z for the merge
<HebaruSan[m]>
Ooh, I can make a reminder in GNOME Shell