# Omega Cloud -- Self-Service Guide (DRAFT)

How to run your environment day to day. You can do everything here yourself,
through the web dashboard or the OpenStack command-line client.

## 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:

1. **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.
2. **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.
3. **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.

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

1. Create the user in your domain.
2. Grant them `member` (and `load-balancer_member` if they manage load
   balancers) on your project.
3. They log 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)

1. Network, then a subnet on it (use the address range from your intake form).
2. Router; set its gateway to the shared external network (`provider-ext`).
3. Attach your subnet to the router.
4. Security groups: open only what you need (SSH from your ranges, your app
   ports).
5. 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.