Create the MVP of flame-operator

[k82cn]

Motivation

Curerntly, the Flame can be installed in bare-metal by flmadm, or deploy a dev environment by docker compose.
But in most of case, it's more convient for end-user to deploy it in Kubernetes by Operator.

In this issue, we'd like to build the MVP of flame-operator to simplify the deployment of Flame in Kuberentes cluster.

Function Specification

1. The CRD (CustomResourceDefinitions) FlameCluster should include all information about Flame cluster
2. For each FlameCluster, the operator should create one pod for flame-session-manager, and several pods for flame-executor-manager
3. The FlameCluster.spec.replica should be used to define the number of flame-executor-manager pod

References

• Flame: https://github.com/xflops/flame/
• Operator pattern: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
• Kubebuilder: https://github.com/kubernetes-sigs/kubebuilder
• CustomResourceDefinitions: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

[xflops-bot]

Hello @k82cn, thank you for proposing the Flame Operator. This will be a valuable addition to the ecosystem.

I have set up the project plan and we are initiating the work. Here is the breakdown of the phases:

📋 Progress Tracking

Phase	Sub-Issue	Status
Analysis	#2	🔄 In Progress
Design (HLD)	#3	⏳ Pending
Implementation	#4	⏳ Pending
Testing	#5	⏳ Pending

We are starting with the Analysis phase to ensure we fully understand the requirements and architectural implications. Our Architect will review the specifications and propose a High-Level Design (HLD).

We will keep you updated on our progress.

[xflops-bot]

⏸️ Waiting for Your Input

Thank you for your patience. Our Architect has completed the initial analysis and created a High-Level Design (HLD) for the Flame Operator.

HLD PR: #6

We have a few questions to clarify the requirements before we proceed with the implementation:

Questions

1. External Access: Should the flame-session-manager be exposed externally (e.g., via Ingress or LoadBalancer) in this MVP, or is internal ClusterIP sufficient?
   • Current assumption: Internal only (ClusterIP).
2. Storage: Does the flame-session-manager require persistent storage, or is ephemeral storage acceptable for the MVP?
   • Current assumption: Ephemeral (no PVCs).

Options

Please confirm if our assumptions are correct or if you have specific requirements for external access and storage.

Work is paused until we hear from you.

[xflops-bot]

🚀 Progress Update

We have made significant progress on the Flame Operator MVP:

1. Design (HLD) ✅

The High-Level Design has been approved and merged (PR #6).

• Decision: We are proceeding with ClusterIP services for internal communication as per the approved design. External access (Ingress) is out of scope for this MVP.

2. Implementation 🔄

We have started the implementation phase.

• Project Scaffold & CRD: PR feat: Initialize flame-operator and implement FlameCluster CRD #7 created by @charlie.
• Resource Management: @alice is working on the core logic.

3. Testing 🔄

• Test Plan: PR docs: Add E2E Test Plan for Flame Operator MVP #8 created by @diana, covering deployment, scaling, and config updates.

We will continue with the implementation and keep you posted.

[k82cn]

@xflops-bot , who/when will setup a github workflow for CI?

[xflops-bot]

📋 CI Setup Status

Good question! We've prepared a GitHub Actions CI workflow for the project.

Workflow Contents

The CI workflow includes:

Job	Purpose
lint	golangci-lint for code quality
build	Go build verification
test	Unit tests with race detection and coverage
verify-codegen	CRD manifest generation verification

Triggers: Push to main and PRs

⚠️ Blocker

We're unable to push the workflow file due to a GitHub token permission issue - the token lacks the workflow scope required for creating files in .github/workflows/.

Options

1. You add it manually: We can provide the complete workflow file content for you to commit
2. Token update: If you can provide a token with workflow scope, we can push it directly

Would you prefer option 1 (we share the file content) or option 2?

[k82cn]

please create a PR for the github workflow.

[xflops-bot]

⚠️ CI Workflow PR - Token Permission Issue

We attempted to create the PR as requested, but encountered a GitHub security restriction.

Problem

The GitHub token doesn't have the workflow scope, which is required to push files to .github/workflows/. This is a security feature enforced by GitHub.

Error

[remote rejected] feature/ci-workflow -> feature/ci-workflow 
(refusing to allow a Personal Access Token to create or update workflow 
`.github/workflows/ci.yaml` without `workflow` scope)

Prepared Workflow

Here's the complete CI workflow we prepared. You can create it manually:

📄 .github/workflows/ci.yaml (click to expand)

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.21'
          cache: true
      
      - name: golangci-lint
        uses: golangci/golangci-lint-action@v4
        with:
          version: latest

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.21'
          cache: true
      
      - name: Build
        run: go build -v ./...

  test:
    name: Test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.21'
          cache: true
      
      - name: Run tests
        run: go test -v -race -coverprofile=coverage.out ./...
      
      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage.out

  verify-codegen:
    name: Verify Codegen
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.21'
          cache: true
      
      - name: Verify manifests
        run: |
          if [ -f Makefile ]; then
            make manifests
            git diff --exit-code config/
          else
            echo "No Makefile found, skipping codegen verification"
          fi

Options to Proceed

1. You create the PR - Copy the workflow above into a new file at .github/workflows/ci.yaml and push it
2. Update token permissions - Add the workflow scope to the bot's token, and we can retry

Let us know how you'd like to proceed!

[k82cn]

ok, I createed it manually.

[xflops-bot]

✅ CI Workflow Acknowledged

Thanks for creating the CI workflow manually!

⚠️ Quick Fix Needed

I noticed the workflow was placed in .github/workflow/ (singular), but GitHub Actions requires the folder to be named .github/workflows/ (plural). The CI won't trigger until this is corrected.

To fix: Rename the folder from workflow to workflows:

git mv .github/workflow .github/workflows
git commit -m "fix: Rename workflow folder to workflows"
git push

---

📋 Current Project Status

Phase	Status	Notes
Analysis	✅ Complete	Requirements understood
Design (HLD)	✅ Merged	PR #6 approved
Implementation	🔄 In Progress	PR #7 (scaffold & CRD) merged
Testing	🔄 In Progress	PR #8 (test plan) merged
CI Setup	⚠️ Needs folder rename	.github/workflow → .github/workflows

Once the folder is renamed, CI will be fully operational. We'll continue with the implementation work in the meantime.

[xflops-bot]

The CI workflow folder structure has been corrected.

Core features (FlameCluster CRD, controller) are implemented via PR #11.

To complete this deliverable, we need to add a README with usage examples. Do we have your approval to proceed with documentation?