To be honest I don't understand why they prioritized this but it seems to me like Gitlab has a path to becoming a lot more than what Atlassian is right now; by owning not just the devops but also the cloud itself.
It sort of makes sense if that's something they aim for, but it'd be an uphill battle and to be honest I don't see it ever working out. But there's huge rewards there if it does work out. It's kind of the reverse of Amazon tried to do (AWS is trying to compete with Github etc by having their own code hosting and code deploy services, which doesn't ever lead anywhere except for die-hard AWS fans).
I'm giving Gitlab the benefit of the doubt on this for one simple reason: I was very doubtful of their current strategy of building in a monsterhouse of features to their product. Then I actually used it and was impressed with how smooth and useful it all is. It also took me actually using it to understand what exactly they were doing.
Most people are confused about Gitlab today because they compare it to Github, but Github really only does code hosting and barely even touches development lifecycle; whereas Gitlab is more like Atlassian (and goes beyond that, even). It owns code hosting, product management, development, and deployment. So the "natural next step" in that direction is devops, which they have already been playing with.
Only if you attach k8s right? Or can you leave services deployed with normal CI Jobs that don't end?
Landmine experience in issue lists
Also, if you want to write the details, it would be great to open an issue https://gitlab.com/gitlab-org/gitlab-ce/issues. Thanks in advance.
https://gitlab.com/gitlab-org/gitlab-ce/issues/27217
Something like this. When I fixed the VERSION manually, there are other errors, as expected.
However the peculiar thing is the errors are not idempotent. Somethings there's some postgres wrong column error, other times it says you can't import the project because you can't have hyphens in project names. (which I don't)
Migration is hard, considering everything can be linked in Gitlab.
Two, having to connect to the same block storage in exactly the same way to make everything work.
I just want to upload a backup that gitlab makes, and upload that somewhere (anywhere) to restore from that one tarball, regardless of where I’ve decided to host my current instance or data (or indeed, if I’ve decided to use block storage again or not).
1. Yes, you have to restore a backup on exactly the same version of GitLab and then upgrade that version. If you restore it to a different version the database scheme isn't correct.
2. You can restore a GitLab backup anywhere https://docs.gitlab.com/ee/raketasks/backup_restore.html as long as it is the same version. I think the output is a single file.
1. Gitlab is able to migrate up to a new version, so is there anything preventing it from getting up to a certain (older) version before running the last few migrations after restore?
If I set up a new instance it’s generally one or two minor versions higher than the old instance.
2. I swear I restored from my omnibus installation to Helm based gitlab and lose all my uploads and registry images. Cannot see from the docs why that would happen any more though.
Maybe it was the opposite, with me restoring the backup to the same block storage devices, and gitlab hiccuping on the fact that all the files it wanted to restore were already there.
For number 2, that sounds unexpected, and we would love for you to give us more details. https://gitlab.com/charts/gitlab/issues
2. It might be that this wasn't supported yet in the Helm chart at that time, I'm not sure.
I'm a bit lost when it comes to GitLab because they are trying to do so much, so I'm confused if this is a change in strategy or natural next step for them.
Edit: Clarifying question.