Unable to Login Due to Remote Auth Service Being Unavailable

I was unable to access my local sickrage instance yesterday because a remote authentiation service was unavailable.
2019-12-29 22:31:52 CORE::503 Server Error: Service Temporarily Unavailable for url: https://auth.sickrage.ca/auth/realms/sickrage/.well-known/openid-configuration
I also tried to come here to log the issue, but was likewise unable to do so as I was unable to log into the forums to post.

This has me more than a little concerned. If the auth site is ever unavailable for any extended period, or worse shutdown for any reason, then my entire sickrage installation becomes immediately null and void. For short blips, I can accept this. For longer or more permanent problems, this is very problematic.
I very much appreciate the effort and time spent by the developer(s) to create and maintain this free software. I also very much realize that sometimes these projects come to an abrupt halt for a variety of reasons (both voluntary and otherwise). In most cases, such an abrupt halt means that I no longer get updates, fixes and new features; but in this case, it means that I can no longer access my locally installed instance. A forced online/connected component is one thing when done by massive corporations like Bilizzard or Microsoft, etc. But for open-source, independent software, it’s another thing, in my opinion.

How can we ensure that access to locally installed sickrage is always accessible regardless of internet connectivity or availability?

Yesterday it was announced there would be downtime possibly related to moving the Auth services into our Kubernetes cluster away from Amazon AWS, no amount of downtime is acceptable to me but was unavoidable due to unforeseen problems during the migration process.

With that being said I can understand you’re concerns that this can cause lockouts from the app it self and its an issue that I’m aware of and plan to work a solution for, partly the reason I moved it into the cluster is so I would have better control of the resources provided to the service including its failover setup.

The entire reason the Auth services were implemented was to tie the app directly to the API service and provide a more secure login mechanism, this allows me to provide further features and improvements to the app via the API without the overhead to the end-user.

I started this project back in 2014 and have brought it to where it is through many struggles, I have no intentions of just jumping ship, I work alone to avoid project issues derived from inner-team issues, this allows me to focus more on code then politics, there are trade-offs of course, things take longer to get done at times but I’d rather that then worry about project halts due to disagreements.

I’ll share more of my thoughts on how I’ll be tackling login issues derived from outages to the auth server later on today.

I hope this has cleared most things up for you,