Omega Cloud -- Self-Service Guide

How to run your environment day to day. You can do everything here yourself, through the web dashboard or the OpenStack command-line client. For a read-only snapshot of everything described here, run the starter-kit script scripts/tenancy-audit.sh delivered with your Handover Pack.

Your three accounts, and what each is for

Account	Use it for	Do NOT use it for
`<you>-domain-admin`	Creating/removing team users and projects, granting roles inside your domain	Running workloads, automation
`<you>-cluster`	Creating and deleting Kubernetes clusters; it holds the SSH keypair for cluster nodes	General automation, team logins
`<you>-svc`	Scripted/automated work via its application credential: networks, VMs, load balancers, day-2 operations	Kubernetes cluster create/delete

Three rules that prevent the three most common self-inflicted outages:

Kubernetes clusters are created with the -cluster account, logged in with its password. The platform's cluster machinery cannot work through an application credential -- a cluster create attempted with the -svc application credential will fail every time.
The SSH keypair for cluster nodes belongs to the -cluster account. Do not recreate it under another account; clusters will refuse to build with someone else's key.
Your -domain-admin account has exactly one job: identity. Give team members their own users and grant member on the project; don't hand out the admin account's password.

As <you>-domain-admin: three error popups appear at login ("Unable to retrieve usage information", "Unable to retrieve compute limit information", and a "local variable 'limits'..." message). These are normal for this account and harmless -- it runs no workloads, so the compute overview has nothing to show it. Dismiss them. The dashboard then shows the Identity section only; that is this account's whole job.
As <you>-cluster or <you>-svc: none of those popups; you land in the full project view (compute, network, volumes, and so on).
Application credentials and SSH keypairs are per-account: the dashboard lists only the ones owned by the account you are signed in as. Your automation credential appears only under <you>-svc, and your SSH keypair only under <you>-cluster -- an empty page under the other account is normal, not a missing resource.

Creating team users (as `<you>-domain-admin`)

Team users are created with the command-line client today -- the dashboard, signed in as <you>-domain-admin, does not offer user creation. As <you>-domain-admin:

openstack user create --domain <your-domain> --password-prompt <username>
openstack role add --user <username> --user-domain <your-domain> \
  --project <your-project> member

Grant load-balancer_member the same way for users who will manage load balancers. The new user then logs in to the dashboard with your domain name + their username.

If a dashboard identity page refuses an action your account should be able to do, use the command-line client for that step and let us know -- the API always has the full capability set.

Building your network (first-time order)

Network, then a subnet on it. Pick any private (RFC1918) range that does not overlap your existing subnets (your handover range is recorded in your Handover Pack) or any on-premises/VPN network you plan to connect.
Router; set its gateway to the shared external network (provider-ext).
Attach your subnet to the router.
Security groups: open only what you need (SSH from your ranges, your app ports).
Public (floating) IPs: allocate from the external network and attach to instances or load balancers.

Virtual machines

Boot from the shared base images or upload your own private images. Use your SSH keypair; password logins are disabled on the base images. Attach volumes for data you want to outlive the instance.

Load balancers

Create load balancers on your networks (you hold the load-balancer_member role already). TLS certificates for listeners are stored in the platform's secrets service under your project -- upload the certificate there and reference it from the listener.

Kubernetes

Log in as <you>-cluster (password), pick the shared cluster template or your own, and create the cluster. Node counts are limited by your quota. The cluster gets its own load balancer for the API and can publish Services of type LoadBalancer through the same mechanism.

When you need us instead

Quota raise, password reset, custodian change: via an authorized requester.
Anything about the shared substrate (new base image, new machine size, external connectivity): via your account contact.