They shutdown the servers because they discovered that at least half of them didn't identify as female.
Please stop posting unsubstantive inflammatory comments (aka trolling).
GitHub was down
191–197 of 197 posts
Re: GitHub was down
#192Earlier quoted context omitted.
> Making your organisation too dependent on a remote service can indeed be a scary prospect At every company I've worked for, internal services have been less reliable than github. Certainly way less reliable than gmail. I get that it's scary, in that it feels like you're giving up control over something important to your business. But I'll posit that you never actually had control, only the illusion of control.
> But I'll posit that you never actually had control, only the illusion of control. That's a weird way of phrasing it. When you run your own services and they break you have total control and do have the power to fix it. When you buy SaaS you are relying on someone else. You may very well have more reliability and uptime but you are nonetheless giving up control.
> When you run your own services and they break you have total control and do have the power to fix it.
If I had total control of a service, I would make it have 100% uptime. Wouldn't you? The fact that there exists no service with 100% uptime indicates to me that nobody has total control of their services.
Similarly wrt having the power to fix my services. If I had unrestricted power to fix things when they broke, then I would use that power to fix all breakages immediately. Since nobody seems to be able to do that, I conclude that nobody actually has unrestricted power to fix breakages in their systems.
Or do you mean to say, I have some limited ability to control and fix the systems I run? I would agree with that. That's my whole point.
Re: GitHub was down
#193Earlier quoted context omitted.
I think GP's point is that you should assume the 0.{however many 0s}1% it's down is going to be a bad time for you, and then ask yourself how long you want to wait to be back up. A long down time might be worse for you than a shorter down time more frequently.
I fail to see how. 99.99999999% uptime is 3 milliseconds of downtime a year. That's not even a TCP retransmission.
Well for a start, ten nines is a lot, isn't it?
If this service is up for five years, then it can go down for 15ms and still claim all ten over that period. Which is almost nothing still, but if you needed ten to begin with then maybe it's quite a lot for you.
All I'm saying is - and I think this is what the commenter originally twice above me meant - is that the rate doesn't give you all the information, you at least need a period as well.
Re: GitHub was down
#194Earlier quoted context omitted.
Thanks for mentioning that. It seems like this bug wasn't reported yet, so I have filed a bug report.
Also, I don’t seem to be able to properly run it in docker (I’m trying to deploy it on kubernetes), do you, by random chance, have experience with deploying gitea?
Sorry, I don't know about running it in docker. My usecase is personal lightweight repos management, so I just download the binary and run it backed by SQLite. Never faced any issues with that. I never needed to go fancy with docker.
Re: GitHub was down
#195Earlier quoted context omitted.
Your question seems to indicate that you have a runtime dependency on github. If true, this is a problem no matter where your git repo resides. You need to architect a solution wherein you do not have a runtime dependency, especially if it is a single point of failure, or accept that your reliability will never be better than the sum of your services' reli abilities (there was an article on the "calculus of availabil…
> you can instead push your artifacts to an s3 target This is our tactic. I tried to do baked AMIs at one point, but the 10-15 minute turnaround in registering them meant that we couldn't use them for staging or testing (too long to iterate changes). Previously we were capistrano-deploying with git from bitbucket - every server had to individually git pull from servers on the other side of the continent, over the pub…
You can speed up AMI baking by using chroot + a mounted EBS volume on a running instance. It should drastically reduce the time it takes to produce a new image. Also be sure that you're building EBS-backed AMI's, as S3-backed AMI's will require a lot of time for copy.
Re: GitHub was down
#196Earlier quoted context omitted.
Your question seems to indicate that you have a runtime dependency on github. If true, this is a problem no matter where your git repo resides. You need to architect a solution wherein you do not have a runtime dependency, especially if it is a single point of failure, or accept that your reliability will never be better than the sum of your services' reli abilities (there was an article on the "calculus of availabil…
Is it still considered a runtime dependency if all you do is merge code and deploy while relying on GitHub? I assume most apps will not go down if GitHub goes down, but their ability to move code to production gets stalled.
Speaking from an operations perspective, yes, it's a runtime dependency. From a development perspective, you might think of it as a "deploy-time" dependency. Think of it in contrast to compile errors. If your program has errors that your compiler can catch, then it will refuse to compile the program and you must fix the error before executing the program. A runtime dependency is one that may change after your program is compiled -- these are harder to test, especially when the program may fail depending on its environment. In the case of dependencies on services such as Github at deploy time, it's a "runtime dependency" for the operations programs. Since the operations programs are the ones with the runtime dependency, it's also in the operations team's purview (and responsibility) to revise their program(s) and eliminate the runtime dependency such that testing (and reproducibility of) deployment is deterministic and reliable.
Re: GitHub was down
#197Earlier quoted context omitted.
Sure, if you measure uptime of your business and dev team by whether you're serving pages. I wouldn't. If Github being down means you're not fixing your site today, I'd call it a runtime dependency.
Incorrect. You need build-time dependencies to change an application, and runtime dependencies to run it. Deploying/scaling is somewhere in the middle.
Yeah, I should have clarified I was talking with my operations hat on. From a development perspective, you might call it a "deploy-time" or "scale up" dependency.