-
Notifications
You must be signed in to change notification settings - Fork 5
feat: initialize HyperFleet API Implementation #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
rh-amarin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to submit comments that appear as "pending" on my GitHub interface
This commit consolidates the migration to HyperFleet v2 architecture with the following changes: - Remove v1 event-driven architecture components (events table, controllers, event DAOs) - Cleanup unused CI/CD pipelines (.tekton, GitHub workflows) - Remove legacy secrets, templates, and build scripts - Standardize naming conventions (nodePool -> node_pool) - Update documentation (CLAUDE.md, PREREQUISITES.md, README.md) - Remove deprecated RHTAP integration files - Simplify codebase structure for pure REST API approach This migration removes the event-based orchestration in favor of Sentinel-driven lifecycle management, aligning with the new HyperFleet architecture design. fix: Update Dockerfile to use hyperfleet-api binary name - Change COPY from hyperfleet to hyperfleet-api - Update ENTRYPOINT to use /usr/local/bin/hyperfleet-api - Update LABEL name to hyperfleet-api - Update summary and description to HyperFleet API - Add secrets directory to .gitignore
- Add /pkg/api/openapi/ to .gitignore - Remove 61 generated files from git tracking - Developers must run 'make generate' after cloning/pulling - Update README with code generation requirements This reduces PR noise and follows best practices for managing auto-generated code. docs: Update README with code generation requirements - Add 'make generate' step to Initial Setup section - Add important note about generated code not being tracked in git - Update code generation workflow documentation - Clarify that developers must run 'make generate' after cloning/pulling
| }' | jq | ||
|
|
||
| # 3. Report adapter status | ||
| curl -X POST http://localhost:8000/api/hyperfleet/v1/clusters/$CLUSTER_ID/statuses \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to add created_at and updated_at
curl -X POST http://localhost:8000/api/hyperfleet/v1/clusters/$CLUSTER_ID/statuses -H "Content-Type: application/json" -d '{
"adapter": "hive-adapter",
"observed_generation": 1,
"conditions": [
{
"adapter": "hive-adapter",
"type": "Ready",
"status": "True",
"observed_generation": 1,
"reason": "ClusterProvisioned",
"message": "Cluster successfully provisioned",
"created_at":"2025-11-17T15:04:05Z",
"updated_at":"2025-11-17T15:04:05Z"
}
]
}' | jq
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember we talked about last_transition_time in the past, is it the created_at value? If yes, created_at is a bit of confusion for customers as I have no idea if created_at means my resources' created_at or current message's created_at. If it means the message's created_at, adapter have no idea if the message created or not as it sends POST all the time, unless it has to query the statues before it posting the status. It makes the logic more complex.
- Rename cmd/hyperfleet directory to cmd/hyperfleet-api - Update go.mod module path to github.com/openshift-hyperfleet/hyperfleet-api - Replace all 223 import path occurrences across 81 Go files - Update Makefile ldflags, binary, and install targets - Verify build compiles successfully with new module name This ensures naming consistency across: - Repository name: hyperfleet-api - Binary name: hyperfleet-api - Go module: github.com/openshift-hyperfleet/hyperfleet-api - Command directory: cmd/hyperfleet-api update update
Initial HyperFleet API Implementation
Summary
This PR introduces the complete initial implementation of the HyperFleet API - a REST API service for cluster lifecycle management. The API provides CRUD operations for clusters, node pools, and adapter status resources with PostgreSQL integration.
Architecture Overview
HyperFleet API follows a simple CRUD-only architecture with no business logic or event creation. The service acts as a pure data layer that enables horizontal scaling through stateless design. All orchestration logic is handled by the Sentinel operator, while adapters manage the specifics of cluster specifications.
Key Features
Core Functionality
Technical Stack
Project Structure
API Endpoints
Clusters
GET /api/hyperfleet/v1/clusters- List clusters with pagination/searchPOST /api/hyperfleet/v1/clusters- Create clusterGET /api/hyperfleet/v1/clusters/{cluster_id}- Get cluster by IDGET /api/hyperfleet/v1/clusters/{cluster_id}/statuses- List adapter statusesPOST /api/hyperfleet/v1/clusters/{cluster_id}/statuses- Create adapter statusNodePools
GET /api/hyperfleet/v1/nodepools- List all node poolsGET /api/hyperfleet/v1/clusters/{cluster_id}/nodepools- List node pools by clusterPOST /api/hyperfleet/v1/clusters/{cluster_id}/nodepools- Create node poolGET /api/hyperfleet/v1/clusters/{cluster_id}/nodepools/{nodepool_id}- Get node poolGET /api/hyperfleet/v1/clusters/{cluster_id}/nodepools/{nodepool_id}/statuses- List all adapter statuses for nodepoolsPOST /api/hyperfleet/v1/clusters/{cluster_id}/nodepools/{nodepool_id}/statuses- Create or update adapter statusDatabase Schema
Clusters Table
id,kind,name,spec(JSONB),labels(JSONB)generation,status_observed_generationstatus_phase,status_last_transition_time,status_updated_at,status_adapters(JSONB)created_at,updated_at,created_by,updated_byNodePools Table
id,kind,name,spec(JSONB),labels(JSONB)owner_id(cluster reference)status_phase,status_last_transition_time,status_updated_atcreated_at,updated_at,created_by,updated_byAdapter Status Table
id,cluster_id,adapter,metadata(JSONB),conditions(JSONB)created_at,updated_atTesting
Integration Tests
Test Infrastructure
GitHub Actions
Documentation
Code Generation
The project includes templates for generating:
Deployment
Local Development
Container Build
Dockerfile: Main application containerDockerfile.openapi: OpenAPI code generation containerMigration Notes
This is the initial implementation, so no migration from previous versions is required.
Checklist
Related Issues
Initial project implementation - no related issues.