> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online.
> Please please don't get complacent. Not yet.
I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit.
It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.
We currently use docker-compose for the development environment. I'm currently simplifying this to allow developers to get started with minimal effort:
The big problem with the way we use neo4j is around huge rooms with ~100K users. The number of possible rooms that neo4j has to traverse (even a shallow traversal) for a user in a big room is huge.
Thanks for your recommendations. I'll definitely check them out.
Gitter co-founder here: we use neo4j for suggesting rooms.
So, if you're in room A and room B, and most people in those two rooms are also in room C, then we suggest that you join room C.
As I mentioned elsewhere, we also use some non-neo4j based methods for suggestions (including your GitHub graph). One of the problems we've had with neo4j is that we haven't been able to make it scale. It frequently burns up from being overloaded.
This is almost certainly down to the way we use neo4j but at some point I'd like to ditch it for a clustered suggestion algo that uses batch processes to cluster rooms together.
Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it.
These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a chance, I would like to remove the dependency we have on neo4j.
We use Ansible / packer & terraform. Open sourcing this repo will be fairly complicated but it may make more sense for us to publish a k8s helm chart or more complete, production-ready docker-compose.yml
We have a docker-compose.yml for development environments and I'm currently in the process of simplifying this[1] so that Docker for Mac/Windows will be able to spin up an environment with little effort.
We use ansible for provisioning beta/staging and production. We have yet to open source the ansible repository but, since we're switching to GitLab CI/CD, the deployment process will soon be publicly accessible - even for production.
Gitter is not intended to be a replacement for Mattermost, Slack or other team collaboration tools. We see Gitter as a community instead.
As such, we're not expecting to see a huge uptake of on-site installations, so the list of required services (es, neo etc) is big compared to other products focused on on-prem.
We're hoping that our users will contribute to the main site, Gitter.im.
Obviously, we're also totally happy with users running their own Gitter installations but, while we would like it to be easy, ease-of-installation of a production instance is not a goal currently.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
Details of how to toggle the canary environment can be found in our handbook: https://about.gitlab.com/handbook/engineering/#canary-testin...