Page MenuHomePhabricator

Request for floating IP / DNS for gitlab-test.wmcloud.org
Closed, ResolvedPublic

Description

Project Name: gitlab-test
Type of quota increase requested: floating ip
Amount of quota increase: 1 (one)

Reason: We've got a test instance of GitLab up for users to experiment with during the just-launched GitLab consultation, and things pretty much work. The piece we're missing is SSH to the underlying GitLab box so people can use SSH as a git transport.

What I think we need for that is gitlab-test.wmcloud.org pointing to a public IP for that machine, rather than using a proxy like we're currently doing, but please let me know if there's a better approach.

Event Timeline

Yeah that would work and is the mechanism that allows people direct access to e.g. the bastions and the tools login machines. The other potential option is just to require people using the test setup to use some custom SSH config to proxy through the bastions to get there.

Approved in meeting on 9 Sept 2020. You should now be able to attach a floating ip.

Thanks! I think I also need to ask for a hostname - that is, ideally people should be able to SSH to gitlab-test.wmcloud.org, and I don't think I can point that at the floating IP myself from Horizon? (It also conflicts with the existing web proxy.)

Thanks! I think I also need to ask for a hostname - that is, ideally people should be able to SSH to gitlab-test.wmcloud.org, and I don't think I can point that at the floating IP myself from Horizon? (It also conflicts with the existing web proxy.)

As you say, this hostname is currently an A record pointed to the shared HTTPS proxy service. There is no port discrimination in DNS, so you will need to either a) pick a different name for your custom ssh endpoint or b) stop using the shared HTTPS proxy and handle TLS termination yourself. The preferred way for handling custom DNS like this would be for us to create a zone matching your gitlab-test project name (gitlab-test.wmcloud.org.) and delegate ownership of that zone to your project. Then you can make DNS records in the zone as needed yourself using Horizon.

The project owned zone and a matching name at the shared proxy is also possible, so you can use the proxy and a related hostname for your ssh endpoint. That might look something like https://gitlab-test.wmcloud.org for the HTTPS endpoint and ssh.gitlab-test.wmcloud.org for the ssh endpoint. This would keep you from needing to handle TLS yourself, but does mean that your git clone URLs would vary on hostname as well as protocol.

or b) stop using the shared HTTPS proxy and handle TLS termination yourself

Yeah, this shouldn't be a problem; the GitLab omnibus setup we're using supports Let's Encrypt by default.

or b) stop using the shared HTTPS proxy and handle TLS termination yourself

Yeah, this shouldn't be a problem; the GitLab omnibus setup we're using supports Let's Encrypt by default.

@nskaggs the runbook for creating and transferring ownership of a zone is at https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/DNS/Designate#DNS_zone_creating_/_transfers. I *think* you will have to remove the current proxy via Horizon before Designate will let you make the zone. Designate is interestingly picky about order of operations and name collisions (and record naming in general honestly).

Mentioned in SAL (#wikimedia-releng) [2020-09-11T19:27:58Z] <brennen> gitlab-test may experience some downtime as a result of zone transfer for T262516, T261900

brennen moved this task from Waiting Response to Done or Declined on the User-brennen board.