Fork: 0
OpenStack / openstack-caracal-ipv4
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-ipv4 / clientdocs / self-service-guide.md
@Jesse Austin Jesse Austin 3 hours ago 5 KB addendum 46: DOCFIX-128 -- handover package consolidation phase 1 (glossary folded into handover-pack, glossary.md removed, account-table hard de-dup, no extra files); skill rewrite phase 2 next
Raw Blame History

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.