Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposed server purchase for GitLab.com

about.gitlab.com

Post reply on HN
Print view View original

321–327 of 327 posts

Re: Proposed server purchase for GitLab.com

#321

Post by tootie »

toomuchtodo wrote: post #132
tootie wrote: post #112

Earlier quoted context omitted.

None of that would convince me to lift a finger. Not unless you put dollar amounts on one vs the other. Version control isn't something I even care about performance.

Version control is the primary tool your developers are using at any org doing software development. It's performance is key to ensure devs aren't wasting their time waiting on version control. Performance along with reliability are the most important metrics for someone providing VCS as a service.

IDE and local dev environment are primary. I'm currently saddled with a proprietary SVN-based enterprisey monstrosity that costs me 10 minutes a day at the absolute worst. It sucks, but we can easily live with it.

Re: Proposed server purchase for GitLab.com

#322

Post by samstave »

closeparen wrote: post #256
samstave wrote: post #147

Earlier quoted context omitted.

What's your email address, SSN and password. If you have nothing to hide, then you shouldn't care why I want to read all your messages.

Why would you care, as in, why would you have cleartext data on the wire? This is Gitlab. There should never be any data in or out except HTTPS and SSH.

thank you. i didnt read it with that context

Re: Proposed server purchase for GitLab.com

#323

Post by discodave »

ninkendo wrote: post #172
manacit wrote: post #144

Earlier quoted context omitted.

I'm happy to see this - I could not agree more with these points. I think they are coming at this problem from the wrong perspective - instead of growing from virtual servers to their own dedicated hardware to get better CephFS performance, they should take a hard look at their application and see if they can architect it in a way that does not require a complex distributed filesystem to present a single mount that t…

I don't see why it wouldn't be difficult to do a git implementation that replaces all the FS syscalls with calls to S3 or native ceph or some other object store. If all they're using NFS for is to store git, it seems like a big win to put in the up front engineering cost. I mean, especially because git's whole model of object storage is content-addressable and immutable, it looks like it's a prime use for generic obj…

That's how AWS CodeCommit works which makes it unique amongst GitHub, Gitlab and friends.

Source: https://aws.amazon.com/codecommit/faqs/

"AWS CodeCommit is built on highly scalable, redundant, and durable AWS services such as Amazon S3 and Amazon DynamoDB."

Re: Proposed server purchase for GitLab.com

#324

Post by scott_karana »

moreati wrote: post #286
scott_karana wrote: post #270

Earlier quoted context omitted.

There's no reason you can't have a hot cloud site, and operate in lipo mode (or even scale it up temporarily) if you lose your DC. Best of both worlds.

What is lipo mode? Closest I can guess is a typo for 'limp mode'.

Haha, yep... was also autocorrected to limo. :(

Re: Proposed server purchase for GitLab.com

#325

Post by jasoncchild »

mverwijs wrote: post #277
jasoncchild wrote: post #187

Earlier quoted context omitted.

I was attempting to confirm that these are all points are important. Being too arrogant to learn and being in incompetent are two entirely different things.

Sorry, I misunderstood. To me, your response came across as a "well, duh!".

No problem; as I read it back to myself I can see how it came across that way.

Re: Proposed server purchase for GitLab.com

#326

Post by lern_too_spel »

sytse wrote: post #139
lern_too_spel wrote: post #63

Since hosting git repositories is core to your business, you should take the time to do it right ( https://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/fi... ) instead of using vanilla git and relying on a magic filesystems and vertical scaling to solve your issues.

The presentation you linked is something we've considered. But it is build on top of Google's distributed filesystem. So we consider our move to Ceph a first step in that journey.

You can swap in any other distributed storage system in jgit or libgit2.

Re: Proposed server purchase for GitLab.com

#327

Post by j45 »

Coming from a complex hosting background - the move to metal is always good one especially when growing. Still, I recommend looking into, where possible using a hypervisor management system like ProxMox where possible.

There is a great deal of pain in moving from one piece of metal to the next, and there is nothing wrong with underpinning your metal with a tech where you can at any time move your architecture to be any combination of a private, public or hybrid cloud, storage aside.

This looks to be a really interesting project, I hope you can continue to blog about it in detail.

Post reply on HN