Hard reference to APIv3 in Mattermost configuration

We make a specific reference to the GitLab Auth endpoint when configuring MM: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L1092

As recent as 9.4.1, that URL was set for APIv3. This means that anyone who has customized this, which you have to do in a few scenarios, will be locked to APIv3 unless they update their gitlab.rb manually.

This seems like a painful challenge for the removal of APIv3.

added Mattermost label

cc @victorwu

added discussion label

cc @smcgivern

added Discussion and removed discussion labels

/cc @stanhu

I think by default most people don't set it. I know I haven't. The default in omnibus is set as such:

"#{gitlab_url}/api/v3/user"

That means we should be able to just bump the version in omnibus. We could add a warning message in omnibus if we detect people are using v3.

For the record, we did bump it by https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1781 . My rationale was we will be specifying it in the blog post.

@balasankarc do we know the conditions where you have to set this?

I think you have to set this in at least two relatively common scenarios but I could be wrong:

1. External database
2. External load balancer that is terminating SSL

I had both of these on my instance, so it's possible that only one of these requires that to be set. That, or I ran into some bug where the default wasn't being applied correctly.

@joshlambert I assume by 'external database' you meant Mattermost running in its own server (that is, we have all other gitlab_rails services turned off via gitlab_rails['enable']=false). If so, yes that is one of the scenarios where one will have to specify this. I am not much familiar with external load balancer to comment on that.

One other scenario is when you are using native Mattermost (not the one bundled with omnibus), and have to configure GitLab SSO as specified in Mattermost docs. We should probably ask Mattermost team to update their documentation to point towards v4.

I'm running an HA cluster, with Mattermost on each node. When setting just the external URL, none of the OAuth configuration was actually set up. Accessing MM simply resulted in being prompted to email register.

Only after going in and setting the URL's did it finally write out the config.json, it seemed.

Because it's HA, I have SSL being terminated on an external load balancer and an external DB. For both GitLab and MM.

This seems like a painful challenge for the removal of APIv3.

If the routes match and behave the same way (which I think they do in this case), we 'fall up' from 3 to 4 anyway, so this will continue to work even after we remove v3 entirely.

@oswaldo is that right? Could you take this, please?

changed milestone to %9.5

As mentioned on https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2633#note_36297776, and pointed on https://gitlab.com/gitlab-org/gitlab-ce/issues/28975#note_35315812, we're OK referring a removed endpoint on V3, since we keep v3 and v4 declared as API versions on Grape. We just need to make sure they behave the same on the integration (which seems to be the case).

But as I can see we've already bumped the version on https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1781.

@joshlambert let me know if that answers the question so we can close this one.

Thanks @oswaldo, if we will gracefully switch this to v4 then that works for me.

closed