New month, new release of Actual Budget. Split transactions came to Mobile this release.

ActualBudget is an open source nodejs/react budgetting app very similar to ynab, but currently users run all their own instances. (It is also is written to fully run in the browser, including the database, with just a file sync server on the backend)

New monthly release just dropped.

We've opened https://gitlab.com/charts/gitlab/issues/1015 to discuss this comment. I don't believe the db migrations are what are holding us back, as much as the other parts of the backup/restore.

For number 2, that sounds unexpected, and we would love for you to give us more details. https://gitlab.com/charts/gitlab/issues

At GitLab, we did evaluate Mesosphere DC/OS. What turned our focus to Kubernetes as our primary cluster install target was the speed at which it was developing, and after watching the space and talking to partners/customers we formed the opinion that Kubernetes was going to lead the pack.

We've been looking at these technologies for two years now, with our focus being Kubernetes for the last one.

At GitLab, our installation method for the product was also tightly based around chef-solo and chef omnibus. At first we were trying to continue using these technologies inside our containers, but this required our containers to run as root.

So a lot of our effort in moving to kubernetes has required us to try and duplicate all of our previous installation work in ways that don't require root access while the containers are running.

To help, we've chosen to use Helm to manage versioning/upgrading our application in the cluster: https://helm.sh/

Our entrypoint configures the unicorn workers before starting using a chef omnibus call. So we grab the memory and cpus using Ohai: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil... and do cpus+1

^This is pretty much we do by default for all our regular package installs, but in some of our Kubernetes Helm charts we instead statically configure the pod resources and unicorn workers. (Defaulting to 1cpu - 2workers per front-end pod) eg: https://gitlab.com/charts/charts.gitlab.io/blob/master/chart...

As someone mentioned in this thread, using the downward api might be a cool way to configure the workers.

We recently heard that we were giving out links to GitLab's documentation instead of our own, (which we didn't have up on our website at the time.) We have since thrown them up here: http://www.perforce.com/perforce/doc.current/manuals/gitswar...