Downtime expected for various dev services

[Moonchild]

I'll be moving some services to a new DC on newly provisioned servers because we're seriously running out of space/resources for them as time goes on and code bases get more mirrors/forks and become larger in general. Yes, this will be an extra expense for the project but trying to squeeze out more performance and hitching up against a 95% full disk isn't a good idea for the long run, especially on Linux where a full disk can be catastrophic.

I expect some extended downtime to occur for the following:

• The cross-reference service https://xref.palemoon.org/
• The Gitea repository service https://repo.palemoon.org/
• The add-ons service for Pale Moon, Basilisk and Epyrus (I'll try to find a date/time that suits Basilisk-dev and Athenian200)

Maybe some other things will be impacted as well but I'll let y'all know if that's the case.

I don't have a set date/time yet for this because provisioning is still in progress but expect this to happen this week and/or the coming weekend.

[dbsoft]

Do I need to start pruning my branches? I've been leaving them around for historical reference purposes... but if they are causing storage problems I can prune them.

[Moonchild]

Do I need to start pruning my branches? I've been leaving them around for historical reference purposes... but if they are causing storage problems I can prune them.

Nah don't worry about it. having branches in repos doesn't take up so much space. I've already provisioned the new server anyway and it'll have plenty of space (>2 TB) so it's all good.

[athenian200]

Is there anything I would need to do to facilitate the transition, or would everything mostly just go back to normal after the downtime is over?

If it's just a matter of waiting, I have no problem waiting until everything is back online. Ideally I wouldn't want things to be down for a month or so, but a couple weeks wouldn't be too big a deal, it's not like Epyrus is a fast-moving project that needs 24/7 uptime.

In my mind, standard amount of downtime for scheduled maintenance would be 24 hours or less, and extended downtime would mean anything over 72 hours.

[Moonchild]

I don't think i'll need 24 hours, but expect 48 hours to be safe.

[Moonchild]

I'm doing this one service at a time, tackling (as you may have noticed) the repo service first. it's currently down and I'm transferring all data. I think it should be back up by tomorrow.

[Moonchild]

Repo should be back up. Let me know if there are issues.

[RealityRipple]

Didn't even log me out... which... I guess that's the price of checking the remember me checkbox, but something deep in my programmer's instinct screams out and says sessions should have been stored in volatile space.

[dbsoft]

Still appears offline to me... am I missing something?

[Moonchild]

Didn't even log me out... which... I guess that's the price of checking the remember me checkbox, but something deep in my programmer's instinct screams out and says sessions should have been stored in volatile space.

Not really for the server side of things. Permanent sessions are stored in a permanent location, and if the database is transferred (which it has been) then session information comes along with it. If the client authenticates properly then it doesn't matter what IP the server is on. Also, if you were to store server-side session info in a volatile space only, then how would you ever manage clusters?

[Moonchild]

Still appears offline to me... am I missing something?

You may have to flush your DNS cache. IP changed.

EDIT: perhaps IPv6 which you seem to use is slower in updating itself. I verified locally that it resolves to the correct IP (v4 and v6) using my public caching recursive DNS resolver (quad9) so there shouldn't be an issue.

[Moonchild]

Okay, it seems the provider offers IPv6 on their services but it needs to be manually enabled. I was not aware of this and had to dig up the instructions. This is new to me.
I'll work on getting IPv6 working soon.

xref has been transferred and should be working.

[Moonchild]

Still appears offline to me... am I missing something?

Please do let me know if IPv6 is working - I tested as well as I could (which isn't very much being on an IPv4-exclusive residential connection) and I think it should all be OK and reachable now over IPv6, but a verification would be nice.

[adoxa]

Looking at Remote address in Network suggests IPv6 is working fine.

[Moonchild]

add-ons site should be back up, concluding this combined downtime.

[Basilisk-Dev]

add-ons site should be back up, concluding this combined downtime.

The Epyrus and Basilisk addons sites are both still down, not sure if you're aware or not.

[Moonchild]

I wasn't aware since I didn't have an easy way to test before DNS was updated.
epyrus is still not resolving right, but I fixed the bad gateway issue on the basilisk site.

[Basilisk-Dev]

I wasn't aware since I didn't have an easy way to test before DNS was updated.

You can test before DNS updates by adding an entry to your hosts file pointing to the IP you provided

[Moonchild]

I had no reason to believe there was an issue since they are literally pointing to the exact same installation of phoebus, and APMO worked just fine.
I found out what the issue was quick enough though and it's been solved. Epyrus is still down since athenian hasn't updated his DNS yet.

[athenian200]

Epyrus is still down since athenian hasn't updated his DNS yet.

I've updated it now...

Honestly, I'm glad I didn't take on anything more essential than an e-mail client, because I just do not have the attentiveness and discipline to seriously manage a project long-term. Like, if I have a short-term mission that can be over and done with, I'm fine, but I'm really bad at keeping up with something that's entirely up to me...

It didn't help that apparently my domain website has changed their UI and a lot of security stuff since I last logged into it and I had to get them to issue me a new password, etc... it's actually much better now than it was, but it still definitely created some delays.