Live data from Hacker News

GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

about.gitlab.com

31–36 of 36 posts

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#31
post #6
post #3

I am curious why you'd need to run monitoring on your own instances, since the assumption is that given a set of resources (say X RAM and Y CPU), you can support Z users. At least I remember they advertised such a number. Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I…

> I am curious why you'd need to run monitoring on your own instances, since the assumption is that given a set of resources (say X RAM and Y CPU), you can support Z users. At least I remember they advertised such a number. We indeed publish a list of requirements https://docs.gitlab.com/ce/install/requirements.html But this is not enough. Not all hardware is created equal (one core is faster than another) and not al…

> If you want to use Prometheus as a SaaS we recommend Weaveworks https://www.weave.works/solution/prometheus-monitoring/

Which is also open source! https://github.com/weaveworks/cortex

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#32

Using Gitlab at our company and I love it. I could never agree with the "small teams don't need/want time tracking" argument, so I'm very happy to see they released it for CE.

I am a bit unsure what Gitlab consider a small team. But I find myself getting a little exasperated when they choose to keep features from CE because "small teams don't need it". Last week I found this was the reason they did not include global contributer statistics in CE. This would be a trivial change, and an important one for my team of ~14 engineers with in-house tools and a microservice architecture who would l…

There are no features that are never needed by a small team. To make our business model work we do need to make some features exclusive to EE. The definition we use is: is this feature more relevant for organizations that have more than 100 potential users? We thought this was the case for timetracking but we were wrong and reversed the decision.

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#33
post #24

Got it running on GKE but the mandatory password change didn't work (request rejected).

Mmm, that is strange, I don't have a clue why that would happen.

It was a CSRF verification error. My wildcard subdomain didn't have a A entry for itself. It's working now! Sorry for the false positive.

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#34
post #24

Earlier quoted context omitted.

Mmm, that is strange, I don't have a clue why that would happen.

It was a CSRF verification error. My wildcard subdomain didn't have a A entry for itself. It's working now! Sorry for the false positive.

No problem, glad to hear you got it running.

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#35
post #9

Earlier quoted context omitted.

Are you on Chrome by any chance? I have exactly same behaviour, which I can't track down.

I haven't gave it much thought, but I'm on Firefox, and my session is sometimes lost (maybe once or twice per month), asking me to re-login...

Same. I'm on Firefox as well and it seems to occur once a month or so.

Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring

#36

Also includes Mattermost in this release. Sweet! >This release migrates project related statistics to a separate table, removing existing columns in the process. This migration process requires downtime, and can take 10-15 minutes for large installations. Any place i can eyeball this upgrade script first? Incidentally, Im curious to know (to try and learn) how do you guys test this kind of stuff? do you have lots of…

It looks like [0] & [1] are the relevant DB migration scripts. GitLab.com is used to test new release candidate versions in a production environment before it is shipped. I'm guessing the 10-15 minute number came from how long it took them to run it on their systems. They do have staging environments where they run migrations (and test new code) on stale prod data as well.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/migra...

[1]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/db/migra...

Post reply on HN