GitLab Appliance - weird issues - performance?

After attempting numerous times to deploy the GitLab appliance from the marketplace ( https://marketplace.opennebula.io/appliance/6b54a412-03a5-11e9-8652-f0def1753696 ) I cannot get past the login page.

I am not currently configuring SSL/HTTPS - this is all HTTP, so I am leaving the relevant contextualization entries blank.

The appliance appears to deploy correctly, shows as “All set and ready to serve” on the console, and the logfiles in etc/one-appliance don’t show any errors.

However, upon connecting to the URL, the login page takes multiple minutes to load - and then when it does appear, the formatting is horribly broken - Times New Roman font, no layout information (but weirdly the logo appears!). I can try to login, but again, after a looooong time (5 minutes+?) it eventually gives me a 401 page - again with logo, but this time with better formatting.

Initially I believed this was a peformance problem, but I’ve now deployed this onto a fast NFS server (I can see relatively low disk latency and no queuing) and it has 24GB of RAM and 4 vCPUs. It’s not resource starved.

The Hypervisor is KVM on Centos7. I’ve tried using a variety of network configurations (vxlan + vrouter, adding it to the management VLAN) but I seem to get the same result. Can anyone suggest what I am missing?


Versions of the related components and OS (frontend, hypervisors, VMs):
GitLab Appliance 13.0.5-5.12.0-1.20200609
OpenNebula 5.10.1
Centos 7

Steps to reproduce:
Using iguane TF provider:

resource "opennebula_image" "GitLab" {
  name = "GitLab - KVM"
  description = "CentOS 7 based GitLab CE appliance"
  datastore_id = 1 
  persistent = false
  lock = "UNLOCK"
  path = "https://marketplace.opennebula.io//appliance/6b54a412-03a5-11e9-8652-f0def1753696/download/0"
  dev_prefix = "vd"
  driver = "qcow2"
  permissions = "660"
  group = var.one_target_group
}
resource "opennebula_template" "GitLabSrvTemplate" {
  name = "GitLab Server"
  template = templatefile("${path.module}/gitlab_srv.tmpl", {
    hostname              = local.gitlab_name
    domain                = var.domain
    vcpu                  = 4
    cpu                   = "4.0"
    mbram                 = "18000"
    oneapp_site_hostname  = "${local.gitlab_name}.${var.domain}"
    oneapp_admin_username = "theusername"
    oneapp_admin_password = "secretpassword"
    oneapp_admin_email    = "geunine@email.provider"
  })
  permissions = "660"
}

resource "opennebula_virtual_machine" "GitLabSrv" {
  name         = local.gitlab_name
  permissions  = "660"
  template_id  = opennebula_template.GitLabSrvTemplate.id
  nic {
    model      = "virtio"
    network_id = var.subnet_id
  }
}

Current results:

Expected results:

Hi @SteveB

I think that the problem is because of bad dns resolving - for example I do not know how this expression gets expanded:

But even if it will be the correct intended result then it may failed due to this:

    hostname              = local.gitlab_name
    domain                = var.domain

HOSTNAME and DOMAIN are not valid context variables (I am not familiar with the terraform provider so maybe I am wrong here) but it should be SET_HOSTNAME as described in the doc. I could not find anything relating to the DOMAIN.

If none above is the issue (terraform provider is actually using SET_HOSTNAME under the hood and appliance itself is resolving to itself via the correct domain name) then the issue could be that your client (browser) is the one not resolving the said domain correctly.

Basically let’s say that your domain is mygitlab.mylocaldomain. If everything is setup correctly then inside the appliance VM you should be able to do:

curl -L http://mygitlab.mylocaldomain

and get the login page html source on the stdout. That would be achieved for example by a correct record in the /etc/hosts:

127.0.0.1 mygitlab.mylocaldomain mygitlab

(with SET_HOSTNAME = "mygitlab.mylocaldomain" it should have been already done)

Also you should be able from your laptop/PC resolve the mygitlab.mylocaldomain and get the IP of the VM or router/firewall/nat and forward correctly the port 80 to the VM.

In the simple scenario when your laptop/PC is on the same network as the VM (with the address 192.168.111.111) you should have also a record in your dns nameserver or simply in /etc/hosts:

192.168.111.111 mygitlab.mylocaldomain mygitlab

Let me know if my hints were useful :slight_smile:

UPDATE: also pls take note that OpenNebula will replace underscores in the domain name to dashes so gitlab_name will become gitlab-name in /etc/hosts and therefore the appliance will never succeed to verify that the gitlab is running - resolving will fail again…this is partially an error in the OpenNebula as of now. Reference: https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it

-osp-