othman.suseno/hephaestus-hpc-api
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
Files
main
hephaestus-hpc-api/srs-sds/SRS_v1.md
Othman H. Suseno eefa9d7035 add srs and sds documents
2025-12-30 13:00:47 +07:00

4.2 KiB
Raw Permalink Blame History

Cloud Infrastructure Management Platform

Software Requirements Specification (SRS)

Version: 1.0 (V1 – Enterprise Foundation)

1. Purpose & Vision

This document defines the Software Requirements Specification (SRS) for the Cloud Infrastructure Management Platform (CIMP).

The platform is designed to deliver enterprise-grade, IaaS-like cloud capabilities inspired by AWS, GCP, and Azure, primarily targeting private and managed cloud environments.

Version 1 focuses on strong architectural foundations, governance, and security, while maintaining a controlled and achievable feature scope.

2. Target Users & Roles

2.1 Tenant Roles

  • Tenant Owner
  • Project Admin
  • Project Operator
  • Project Viewer

2.2 Provider / Operator Roles

  • Cloud Operator
  • Infrastructure Administrator
  • Security / Audit Administrator
  • Break-glass Super Administrator

3. Scope Definition

3.1 In Scope (V1)

  • Multi-tenant and multi-project architecture
  • Identity and Access Management (RBAC)
  • Compute service (Virtual Machine lifecycle)
  • Basic virtual networking
  • Basic storage service (block or object)
  • Asynchronous job execution
  • Audit logging (append-only)
  • Usage metering and reporting
  • Provider / operations management console

3.2 Out of Scope (V1)

  • Public cloud federation
  • Auto-scaling and elasticity
  • Kubernetes and container orchestration
  • Application marketplace
  • Billing or payment gateway
  • Advanced SDN automation (BGP / EVPN)

4. Functional Requirements

4.1 Identity & Access Management

  • The system SHALL support Organizations (Tenants), Projects, Users, Roles, and Role Bindings.
  • The system SHALL enforce strict separation between tenant and provider scopes.
  • The system SHALL use token-based API authentication.
  • The system SHOULD be extensible to support external Identity Providers (OIDC).

4.2 Project & Resource Management

  • Tenants SHALL be able to create and manage projects.
  • Projects SHALL support quota assignment.
  • Every resource SHALL belong to exactly one project.
  • All resources SHALL include ownership and lifecycle metadata.

4.3 Compute Service

  • Tenants SHALL be able to create Virtual Machines from predefined images.
  • The system SHALL support start, stop, reboot, and delete operations.
  • VM provisioning SHALL be asynchronous.
  • VM lifecycle states SHALL be exposed through the API.

4.4 Network Service

  • Tenants SHALL be able to create virtual networks per project.
  • Virtual networks SHALL enforce isolation between projects.
  • Virtual machines SHALL be attachable to one or more virtual networks.

4.5 Storage Service

  • Tenants SHALL be able to create storage volumes or object buckets.
  • Storage resources SHALL be attachable to compute resources where applicable.
  • Snapshot functionality MAY be supported depending on backend capability.

4.6 Job & Workflow Management

  • All infrastructure-impacting operations SHALL be executed via an asynchronous job system.
  • Each job SHALL return a job identifier.
  • Job execution status SHALL be queryable.

4.7 Audit Logging

  • The system SHALL record all control-plane actions.
  • Audit logs SHALL include actor, action, target resource, timestamp, and result.
  • Audit logs SHALL be immutable and append-only.

4.8 Metering & Reporting

  • The system SHALL collect usage metrics for compute, network, and storage.
  • Usage reports SHALL be generated per project and tenant.
  • Billing integration is out of scope for V1.

4.9 Provider / Operations Management

  • Operators SHALL be able to onboard infrastructure clusters.
  • Operators SHALL be able to define global policies and catalogs.
  • Operators SHALL have visibility into tenant activities for auditing and troubleshooting.

5. Non-Functional Requirements

5.1 Security

  • RBAC enforcement at the API layer.
  • Encryption for sensitive data at rest.
  • Full auditability of administrative actions.

5.2 Availability

  • Control plane services SHALL be stateless.
  • The system SHALL tolerate service restarts without data loss.

5.3 Scalability

  • Horizontal scalability for API services.
  • Asynchronous processing for long-running tasks.

5.4 Maintainability

  • Modular service architecture.
  • Clear separation between control plane and data plane.