Expand lab seed tiers, OpenAPI PARAMS, and console DATA/Params UX.
This commit is contained in:
+24
-31
@@ -9,28 +9,32 @@ so labs are reproducible. Definitions live in
|
||||
```bash
|
||||
make seed # default: large (10 hosts / 1000 VMs)
|
||||
VSPHERE_PROFILE=small make seed
|
||||
VSPHERE_PROFILE=big make seed
|
||||
```
|
||||
|
||||
## Profiles
|
||||
|
||||
| Profile | Contents |
|
||||
|---|---|
|
||||
| `small` | 3 ESXi hosts, 2 datastores, 2 networks, one datacenter/cluster/resource-pool, and five named VMs: `web-01`, `web-02`, `db-01`, `app-01`, `jumpbox` (mixed power states). Used by unit/integration tests. |
|
||||
| `large` (default) | Configurable hosts/VMs (`SEED_VSPHERE_LARGE_HOSTS` default 10, `SEED_VSPHERE_LARGE_VMS` default 1000), 4 datastores, 4 networks/portgroups, a `VmwareDistributedVirtualSwitch`, production/staging/templates VM folders. The first five VMs match the `small` names for cookbook stability; the rest are generated (`web-`, `app-`, `db-`, `cache-`, `batch-`, `jump-`, `ci-`, `mon-`, `log-`, `ml-` role prefixes). |
|
||||
| `demo-cluster` | `large` with 20 hosts / 1000 VMs — an enterprise-shaped dataset for UI demos. |
|
||||
| Profile | Hosts | VMs | Datastores | Networks | Folders† | Content extras |
|
||||
|---|---:|---:|---:|---:|---:|---:|
|
||||
| `minimal` | 3 | 5 | 1 | 1 | 8 | ×1 |
|
||||
| `small` | 3 | 50 | 2 | 2 | 8 | ×1 |
|
||||
| `large` (default) | 10 | 1000 | 4 | 4 | 10 | ×2 |
|
||||
| `big` | 20 | 2000 | 8 | 8 | 14 | ×4 |
|
||||
|
||||
Every profile also seeds the four lab credentials, role-scoped permissions
|
||||
(see [Authorization](domains/authz.md)), and — where the platform tables
|
||||
exist — a starter content library, tag categories/tags, and datastore file
|
||||
metadata (`seed_platform_extras`).
|
||||
† Spine folders (8) plus scaled team folders for larger tiers.
|
||||
|
||||
`demo-cluster` remains an alias of `big`. Reset / unload loads `minimal`.
|
||||
|
||||
## Examples
|
||||
|
||||
```bash
|
||||
make seed # large, 10 hosts / 1000 VMs
|
||||
VSPHERE_PROFILE=small make seed
|
||||
VSPHERE_PROFILE=demo-cluster make seed
|
||||
VSPHERE_PROFILE=big make seed
|
||||
VSPHERE_PROFILE=large VSPHERE_HOSTS=20 VSPHERE_VMS=5000 make seed
|
||||
|
||||
# 100% seed ↔ live inventory dump
|
||||
VSPHERE_PROFILE=big make vsphere-seed-dump
|
||||
```
|
||||
|
||||
Or run the seed CLI directly with the underlying environment variables (for
|
||||
@@ -43,28 +47,17 @@ SEED_VSPHERE_PROFILE=small \
|
||||
|
||||
## Topology shape
|
||||
|
||||
Every profile builds the same skeleton (`Datacenters` folder → `Datacenter` →
|
||||
host/vm/datastore/network sub-folders → one `ClusterComputeResource` +
|
||||
`ResourcePool`), then scales hosts, datastores, portgroups, and VMs. VM MOIDs
|
||||
are `vm-{100+n}`; host MOIDs are `host-{10+n}`; each VM carries the same
|
||||
hardware shape used by both REST (`hardware/*`) and SOAP (`VirtualMachineConfigInfo`)
|
||||
responses — NICs, disks, CD-ROM, boot order, and a synthetic guest IP/filesystem.
|
||||
Every profile builds the same spine (`Datacenters` → `Datacenter` → host/vm/
|
||||
datastore/network folders → one `ClusterComputeResource` + `ResourcePool`),
|
||||
then scales hosts, datastores, port groups, and VMs. VM MOIDs are `vm-{100+n}`;
|
||||
host MOIDs are `host-{10+n}`.
|
||||
|
||||
## Demo cluster via UI
|
||||
## Web UI
|
||||
|
||||
The interactive console can load the demo dataset and reseed on demand:
|
||||
The **DATA** panel exposes three load buttons matching these tiers. Each call
|
||||
is `POST /ui/api/vsphere/seed?profile=small|large|big` (atomic reseed).
|
||||
|
||||
- `POST /ui/api/demo/load` — loads `demo-cluster`
|
||||
- `POST /ui/api/demo/unload` — wipes API-created state, then loads `small`
|
||||
- `GET /ui/api/demo/state`
|
||||
- `POST /ui/api/vsphere/seed?profile=small|large|demo-cluster` — reseed any profile
|
||||
Legacy endpoints:
|
||||
|
||||
These UI helper endpoints are development-oriented and are not separately
|
||||
authenticated today. Treat them as lab controls only.
|
||||
|
||||
## Reseed vs client state
|
||||
|
||||
Terraform, Pulumi, and Ansible may still hold resource state after a reseed
|
||||
(VM MOIDs and names can change). Refresh or destroy/recreate external state
|
||||
after replacing the PostgreSQL inventory. See [Operations](operations.md) and
|
||||
[Clients](clients.md).
|
||||
- `POST /ui/api/demo/load` → `big`
|
||||
- `POST /ui/api/demo/unload` → `small`
|
||||
|
||||
Reference in New Issue
Block a user