Provisioning Wizard
The Provisioning Wizard guides administrators through the multi-step process of creating a new tenant on the MATIH platform. It orchestrates namespace creation, secret provisioning, service deployment, DNS configuration, and initial data setup through a progressive wizard interface.
Wizard Steps
| Step | Title | Description |
|---|---|---|
| 1 | Tenant Details | Name, slug, billing tier, contact information |
| 2 | Infrastructure | Cloud provider, region, resource tier selection |
| 3 | Data Sources | Configure initial database connections |
| 4 | Service Selection | Enable/disable platform modules |
| 5 | Security | Authentication method, MFA policy, network restrictions |
| 6 | Review | Summary of all configuration before provisioning |
| 7 | Provisioning | Real-time progress of provisioning phases |
Provisioning Phases
The wizard triggers the backend Tenant Service provisioning pipeline which executes these phases:
| Phase | Action | Duration |
|---|---|---|
| 1. Namespace | Create Kubernetes namespace with labels | Seconds |
| 2. Secrets | Deploy required secrets (DB, Redis, API keys) | Seconds |
| 3. Data Infrastructure | Deploy PostgreSQL, Redis, Kafka per tenant | 2-5 minutes |
| 4. Control Plane | Deploy tenant configuration services | 1-2 minutes |
| 5. Data Plane | Deploy AI, ML, Query Engine services | 3-5 minutes |
| 5.5. Ingress | Deploy NGINX, DNS zone, TLS certificate | 1-3 minutes |
| 6. Observability | Deploy monitoring and logging stack | 1-2 minutes |
| 7. Validation | Run health checks across all services | 30 seconds |
Progress Tracking
The wizard displays real-time provisioning progress:
interface ProvisioningStatus {
tenant_id: string;
current_phase: number;
total_phases: number;
phase_name: string;
status: 'pending' | 'in_progress' | 'completed' | 'failed';
progress_percentage: number;
logs: string[];
started_at: string;
estimated_completion: string;
}Tenant Configuration Form
Step 1: Tenant Details
| Field | Type | Required | Validation |
|---|---|---|---|
| Tenant name | Text | Yes | 3-100 characters |
| Slug | Text | Yes | Lowercase alphanumeric, unique |
| Description | Text | No | Max 500 characters |
| Billing tier | Dropdown | Yes | Starter, Professional, Enterprise |
| Admin email | Yes | Valid email format |
Step 2: Infrastructure
| Field | Options | Default |
|---|---|---|
| Cloud provider | Azure, AWS, GCP | Azure |
| Region | Provider-specific regions | Nearest |
| Resource tier | Small, Medium, Large | Medium |
| Dedicated compute | Yes/No | No |
| GPU enabled | Yes/No | No |
Step 4: Service Selection
| Module | Default | Description |
|---|---|---|
| Core (AI + Agents) | Enabled | Conversational analytics engine |
| BI Platform | Enabled | Dashboards, visualization, reporting |
| ML Platform | Disabled | Model training and serving |
| Data Platform | Disabled | Pipeline and catalog management |
| Context Graph | Enabled | Knowledge graph integration |
Error Handling
If provisioning fails at any phase, the wizard provides:
| Information | Description |
|---|---|
| Failed phase | Which phase encountered the error |
| Error message | Human-readable error description |
| Recovery options | Retry current phase, rollback, or contact support |
| Logs | Detailed provisioning logs for debugging |
Rollback
Failed provisioning can be rolled back, cleaning up partially created resources:
const handleRollback = async (tenantId: string) => {
await apiClient.post(`/api/v1/tenants/${tenantId}/rollback`);
};Access Control
Only Platform Admins can initiate new tenant provisioning. Tenant Admins can request provisioning changes (resource tier, module enablement) through a change request workflow.