Common tenant issues

Use these checks before changing tenant resources. They focus on tenant-visible state and avoid platform operator commands.

Cannot log in to Skyline

Check:

• You used the mustelinet invite link to complete registration.
• You registered through GitHub at auth.mustelinet.com.
• You are using https://skyline.openstack.mustelinet.com.
• The mustelinet team has configured your project group permissions.

If registration is complete but Skyline still denies access or shows no project, wait for group permissions to be applied.

Cannot log in from the Skyline console

Check:

• The VM is active and has finished booting.
• You selected Login Type Password when creating the VM, or you successfully used Set Password or Change Password later.
• You are using the correct image username, such as ubuntu for Ubuntu, debian for Debian, or fedora for Fedora Cloud.

If login says Login incorrect, wait a minute after boot and retry with the correct image username.

Set Password or Change Password fails

Check:

• The VM is active.
• The image has qemu-guest-agent installed and running.
• The VM was created after QEMU Guest Agent metadata was enabled for the image, so Nova attached the guest-agent channel at boot.
• You are using a supported general-purpose server or cloud image.

If the VM was created before guest-agent support was enabled, rebuild or recreate the instance from a supported image, then use Set Password or Change Password again. Do not assume Skyline can recover access to every existing VM; rescue or rebuild is still the recovery path for an inaccessible VM without guest-agent support.

Cannot SSH to a VM

Check:

• The VM is active.
• The VM has an associated floating IP.
• A mustelinet SSH route exists for the VM.
• The security group allows TCP 22 from 0.0.0.0/0.
• You are using the image default user, such as ubuntu for Ubuntu.
• Your GitHub-registered user has the required project group permission.

Root SSH is denied by policy.

mustelinet SSH route missing

Check:

• The VM is in the project you expect.
• The VM has a floating IP associated to the instance port.
• The VM was created recently and route generation may still be reconciling.
• The instance name is clear enough to identify in generated route views.

If it remains missing, record the project, instance name, instance ID if visible, floating IP, and creation time.

Web app DNS name resolves but the app does not load

Check:

• The floating IP is associated to the correct VM or load balancer.
• The app is listening on the expected port.
• The security group allows TCP 80 and/or TCP 443 from 0.0.0.0/0.
• The app responds from inside the VM or load balancer network.
• The generated hostname is the hostname used by the browser or client.

DNS resolution only proves the name exists. It does not prove the app is listening or allowed by security groups.

HTTP works but HTTPS fails

Check:

• The app listens on port 443.
• The app certificate covers the hostname users visit.
• The app is not redirecting to an internal-only hostname.
• The client is using the generated DNS name, not the tenant floating IP.
• Security groups allow TCP 443 from 0.0.0.0/0.

Floating IP is allocated but not associated

An allocated floating IP belongs to your project, but it is not useful until associated to an instance port or load balancer.

Open Network, Floating IPs, then associate it with the intended origin. Release unused floating IPs to free quota.

Security group missing inbound rule

If a port is blocked:

• Add the narrowest inbound rule that matches the access path.
• Use the expected port, such as 22, 80, 443, or 25565 when enabled.
• Use source 0.0.0.0/0 for the standard mustelinet SSH and public HTTP/HTTPS paths.
• Do not use the end user's public IP as the source for proxied paths; the VM sees the mustelinet proxy or edge as the source.
• Remove broad test rules after troubleshooting.

Generated DNS route has not appeared

Check:

• The floating IP exists.
• The floating IP is associated to the VM or load balancer.
• At least 15 seconds have passed since the association.
• You are viewing the correct project.
• The Skyline DNS or Designate page is refreshed.
• Floating IP metadata views are refreshed, if your project exposes them.

Generated records are created automatically from OpenStack inventory, usually within 15 seconds after floating IP association.

Managed Kubernetes cluster creation appears stuck

Check:

• The selected template is k8s-capi-helm-ubuntu-v1.34.7 when that is the expected tenant template.
• Project quota allows the requested master count, worker count, and flavors.
• Master count is odd, such as 1, 3, or 5.
• Master flavor is m1.medium or larger.
• Required networks, SSH keypairs, and security groups exist.
• The cluster has not reached a final failed state.

Cluster creation can take time. Temporary backend polling errors do not always mean final failure.

What to record for an issue

Record:

• Project name.
• Resource name and ID when visible.
• Floating IP and generated DNS name, if relevant.
• Timestamp and timezone.
• Screenshot or copied error text from Skyline or the client.
• Whether the resource was created by Skyline or Terraform.

Do not include secrets, private keys, kubeconfigs, clouds.yaml, Terraform state, or application credential secrets.