Each package in the repository is consistes of serveral json files. Example, see jenkins package. Each number represents a version.
package.json contains the package information.
resource.json contains assets necessary for the package in case the package is being installed in closed environment.
config.json configuration for the package
marathon.json.mustache core definitions of the docker containers.
We kept running into issues with the external db, where things were just hung and no errors were seen before the health check killed the process. Need to look into our connection wait timeout in gitlab to see how soon it timesout so we can adjust healthchecks accordingly.
Realised the way we're doing persistent volumes is wrong - so we need to fix that. We also need to ensure we have a PR up for installation documentation available at the same time as we merge.
DJ MountneyMarked the task add stmp options to the template as completed
Marked the task add stmp options to the template as completed
DJ MountneyMarked the task Add GitLab EE install option to the template as completed
Marked the task Add GitLab EE install option to the template as completed
DJ MountneyMarked the task fix the persistant volumes to support multiple instances running. (don't persist sockets, config) as completed
Marked the task fix the persistant volumes to support multiple instances running. (don't persist sockets, config) as completed
@marin, yes, that could be it. We are still running migrations first, as part of bringing up the docker image, and then after it is up the intent was to run the schema load, and seed_fu (basically undoing all the migration work) So it's possible that getting the gitlab:db:configure change in would also help.
We got stuck today on the persistent storage. Something is chowning the postgres data directory to root. We will be investigating in the meantime, and continue our meetings on Tuesday.
We figured out what was going on with the chown, and had it reported and adjusted in DC/OS. With that fix our template seems to be working as intended, but requires DC/OS 1.8 which isn't released yet. Our Tuesday meeting got pushed to Friday. So we will learn more then.
While I am gone on vacation for the next two weeks, Collin and Sunil are going to continue with the remaining tasks around the documentation/tutorial.
@marin has been left as technical contact, and @eliran.mesika for anything else
Met with the Mesosphere guys again today, we were re-testing the package.
external volumes still aren't working for us, they are going to investigate on their side this week, and we will drop support for them in the GitLab package for now if we can't get them working
SSH support has stopped working. Since we last had it working, we've moved the mounted directories, moved to a different version of GitLab (an 8.10 RC) and to the 1.8dev version of DC/OS, so this week I will explore which of those broke it, and what we can do to fix it.
Other than that this week we are trying to walk through a gitlab - jenkins CI/CD demo, and I will be giving an overview of GitLab CI to them on Thursday, so we can start thinking about how to make that, and registry, work with mesosphere.
SSH problem has been fixed. I had changed omnibus' git user home directory, but hadn't actually changed it on the OS. I turned back on manage_accounts for gitlab on mesosphere, and it is working again.
@twk3 If you run into issues with bundled registry, we should consider using official container with the same version we bundle to make things move faster.
DJ MountneyMarked the task Fix Git SSH, (our keys are being denied atm for some reason, they were previously working) as completed
Marked the task Fix Git SSH, (our keys are being denied atm for some reason, they were previously working) as completed
Today we ran through an intro to GitLab CI. Sunil has two proposals he is going to email out for how we might want to persue support. Other than that we tested the registry. The only difficulty we ran into was http vs https. In order to use it (just for a test) I had to turn off auth on the registry. It seemed to otherwise work. Not sure the best solution to the auth issue yet.
DJ MountneyMarked the task Update package to GitLab 8.10 as completed
Marked the task Update package to GitLab 8.10 as completed
Discussion is progressing on the external volumes issue https://github.com/emccode/rexray/issues/511, the current PR still has support for external volumes, so is waiting on that
Optionally:
Registry support will require us to add some new config options to the PR, so if the PR is still open because of the when we figure the registry out, it's likely registry config options may go into the PR before it is merged
The registry issue may have been related to the version of gitlab we were running. Production had the same problem for a while. I will try again this week with 8.10.3 to see if the auth problems are fixed with the registry.
Today we decided to drop the persistent volume support. This is due to it not being easy to update your install to newer GitLab versions if you are using persistent volumes. In it's place we added support for host pinning, which makes sure your app keeps coming up on the same host. A trade-off of fall-over resilience for ability to upgrade. The hope is that better backup and restore tools will enable us to revisit upgrades on persistent volumes in the future.
The good news is that we think external volumes are working. We ran out of time today to finish testing them, but they looked very promising.
With these changes what is left to do now is:
Current package needs to be retested (single node normal, single node with external volumes, and HA mode)
A quick start quide needs to be created (there is a shared google doc where sunil and I will be collaborating next week)