# 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

You have three accounts: `<you>-domain-admin` for managing your team's users and
projects, `<you>-cluster` for creating and deleting Kubernetes clusters (with
its password; it holds the cluster SSH keypair), and `<you>-svc` for all other
automation via its application credential. The full table of exact rights is in
the Handover Pack, section 2.

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.

## What to expect on first login (dashboard)

- 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)

1. 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.
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. The cluster gets its own load balancer
for the API and can publish Services of type LoadBalancer through the same
mechanism.

Size the cluster against TWO limits, not one. Your quota is the first. The
second is the physical capacity free on the platform right now: a request
that is inside your quota can still fail to place a node, with a node stuck
in ERROR and "No valid host was found. There are not enough hosts
available." That is not a quota problem. Start small (one control node and
one or two workers), confirm it comes up, then scale the worker count up.

If you create your own template, two rules keep the create from failing.
First, use the calico network driver -- do NOT choose flannel, which never
finishes coming up (the create sits in progress and the nodes never go
Ready). Second, leave the Public and Hidden checkboxes unchecked: templates
are project-scoped, publishing cloud-wide is operator-only, and setting
either flag makes the whole create fail with the generic "Error: Unable to
create cluster template."

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