<DasSkelett[m]>
Sounds like we have to do some custom method patching.
<VITAS[m]>
is dig needed?
<VITAS[m]>
i use the dns name for db server too
<VITAS[m]>
and that works well
<DasSkelett[m]>
No no, I just tried it out on the terminal to make sure web1.52k resolves correctly.
<VITAS[m]>
yes and i use db.52k in the config.ini
<VITAS[m]>
and that works
<VITAS[m]>
or was it psq.52k
<VITAS[m]>
psql.52k
<VITAS[m]>
but you know the ins and outs of python better than i do :)
<VITAS[m]>
i would suggest hosts entries but its very important that we use as few workarounds and customizations as possible. we will forget about them in the the future and wonder why stuff isnt working
<DasSkelett[m]>
Nah, I don't want to set a host entry for spacedock.info in the container, that could mess up other things and is hard to debug and maintain. I have a working PoC python script that purges the cache, so I think we can do it all in Python.
<VITAS[m]>
if theres something i could do to the dns setup tell me
<VITAS[m]>
as i said powerdns server as nameserver for 52k connected to powerdns resolver that has a forwarding rule for said tld
<VITAS[m]>
(in fact that setup exists twice on .5 and .40)
<VITAS[m]>
so youre saying: we add a setting to config to set the resolver/dns?
<DasSkelett[m]>
No no, we don't. I'll push to <span class="d-mention d-user">HebaruSan</span>'s branch, you can see what we do in the PR then.
<VITAS[m]>
k
<VITAS[m]>
btw i expect you guys to tell me when you want to scedule another update of prod
<VITAS[m]>
(this time without those complications please)
<DasSkelett[m]>
🤷♂️
<VITAS[m]>
we should talk about what we can learn from the problems we had last time and you could seed the beta db
<VITAS[m]>
we should also deploy it on prod stage first and check it before we annouce downtimes
<VITAS[m]>
im old my heart wont take it if we have those tense situations every time :)
<DasSkelett[m]>
So are you planning to clone the db beforehand the next time?
<VITAS[m]>
no stage uses the prod db
<VITAS[m]>
so we can deploy software to it but not migrate the db
<DasSkelett[m]>
But then how do you want to avoid taking prod down when updating stageing?
<VITAS[m]>
for the actual deployment i have my ansible playbook
<DasSkelett[m]>
Prod will crash very hard if we update the db via staging before updating the coode on live.
<VITAS[m]>
as i said no db migration for testing
<VITAS[m]>
on staging
<VITAS[m]>
when we actualy deploy stuff to live the ansible script will do it
<DasSkelett[m]>
What should we actually test on staging then?
<VITAS[m]>
dont know
<VITAS[m]>
im offering options
<DasSkelett[m]>
We can't just update the code but not the db, that won't work.
<VITAS[m]>
thats why you wrote the seeding script
<DasSkelett[m]>
The code depends on the db having the right version.
<DasSkelett[m]>
Huh?
<VITAS[m]>
i know it does
<VITAS[m]>
what im saying is: that are the possibilities
<VITAS[m]>
and you investigated seeding beta db to hopfully find problems with more than one mod
<VITAS[m]>
or user
<DasSkelett[m]>
I'm not sure I know what you're speaking of now.
<VITAS[m]>
all i can offer to test stuff with prod db data for now is using the current live schema
<DasSkelett[m]>
But we can't test without db upgrades........
<DasSkelett[m]>
Code expecting db version A doesn't work with db version B. We have to update both at the same time.
<VITAS[m]>
again:
<VITAS[m]>
beta db can be upgraded and you did build a seeding script to add test data to it didnt you?
<VITAS[m]>
so we can at least see if there are problems from having more than one entry
<DasSkelett[m]>
Weren't we talking about your new staging container, not beta?
<VITAS[m]>
then
<VITAS[m]>
i could clone prod db if we must and make it available on prod-stage
<VITAS[m]>
to test things right before we deploy
<VITAS[m]>
i would prefer not to do that but as you say you cant test without schema updates
<VITAS[m]>
the ansibble script that actualy deploys new stuff to prod doesnt update the schema before switching to prevent old code writing to new db schema vers
<VITAS[m]>
so no testing when using that
<VITAS[m]>
(as i originaly hoped)
<VITAS[m]>
switching=making prod-stage prod-ive (aka serving under spacedock.info) and vice versa)
<DasSkelett[m]>
Sorry, I can't follow you.
<VITAS[m]>
still?
<DasSkelett[m]>
You are talking about both beta and staging at the same time. Not sure what you actually mean now.
<VITAS[m]>
in sequence
<VITAS[m]>
im talkign about testing procedures, orders and how we can do it (and how we cant and why))
<VITAS[m]>
to find bugs that stem from multiple entries in the db
<VITAS[m]>
(remember we had one problem because we didnt test the code with more than a hand full mods)
<VITAS[m]>
k
<VITAS[m]>
maybe we should have a voip thingy at some point
Darklight[m] has joined #spacedock
<Darklight[m]>
If you do any upgrade, I'd pull in the png fix (and possibly only that if you feel alpha/beta aren't stable for merging, but that is dasskellet/herbarusan area)
<Darklight[m]>
I have been super busy lately >.<
<DasSkelett[m]>
No way we are cherry-picking individual commits again.
<VITAS[m]>
im not at home this week
<VITAS[m]>
we should do a voip call next week to clear questions and missunderstandings
<Darklight[m]>
There's nothing wrong with doing so if you trash the branch afterwards
<Darklight[m]>
And it'
<Darklight[m]>
And it's not a db upgrade
<Darklight[m]>
Iirc
<Darklight[m]>
But that png thing is probably the only thing people can see that they'll care about
<VITAS[m]>
Darklight: germaan percentage is high here :D
<DasSkelett[m]>
Here you go <span class="d-mention d-user">VITAS</span>:
<DasSkelett[m]>
Good point, we should keep it generic. `spacedock.info` will be easy, have to think about how to solve this for `web1.52k`.
<VITAS[m]>
just have config.ini contain an rev proxy value
<VITAS[m]>
and add a description that its tailored towards ATS
<VITAS[m]>
i doubt there are any other sites using the code
<VITAS[m]>
but still
<VITAS[m]>
apart form that good work (i presume it works?)
<DasSkelett[m]>
Well my testing script that I posted above does work, which essentially does the same. I can't say whether it works integrated in the codebase before we merge it.
<VITAS[m]>
uhm cant we test it on beta ?
<VITAS[m]>
it should show if you port a mod and then delete it and recreate it
<VITAS[m]>
post
<DasSkelett[m]>
Yes, even alpha, but we have to merge it first.
<VITAS[m]>
oh yes right
<VITAS[m]>
way to hot here
Github[m] has quit [Quit: Idle timeout reached: 10800s]
Darklight[m] has quit [Quit: Idle timeout reached: 10800s]
Webchat425 has joined #spacedock
Webchat425 has quit [Client Quit]
DasSkelett[m] has quit [Quit: Idle timeout reached: 10800s]
VITAS[m] has quit [Quit: Idle timeout reached: 10800s]
DasSkelett[m] has joined #spacedock
<DasSkelett[m]>
<span class="d-mention d-user">HebaruSan</span> I'll do the config change on alpha
<HebaruSan[m]>
Thanks for the help on that <span class="d-mention d-user">DasSkelett</span>, I submitted a rough outline of an idea and I came back to fleshed out functionality
<DasSkelett[m]>
Thank you for searching through the docs and finding the feature, I myself would've probably tried to implement the more complex workaround with random/unique file names...
<DasSkelett[m]>
And for catching the threading issue, these would've been some nasty bugs to fix! 🙂
<HebaruSan[m]>
I think I just searched for "apache traffic server cache purging" 😉
RSSBot[vitas52kde][m] has joined #spacedock
<RSSBot[vitas52kde][m]>
Announcements Latest Topics: Kerbal Space Program 1.10.1 is live! ( https://forum.kerbalspaceprogram.com/index.php?/topic/195919-kerbal-space-program-1101-is-live/ )
<VITAS[m]>
so time to add it?
<VITAS[m]>
done
DasSkelett[m] has quit [Quit: Client limit exceeded: 6]
HebaruSan[m] has quit [Quit: Idle timeout reached: 10800s]
RSSBot[vitas52kde][m] has quit [Quit: Idle timeout reached: 10800s]
VITAS[m] has quit [Quit: Idle timeout reached: 10800s]