From 025e071fa1f93db01191b959ca627e54424ffc1f Mon Sep 17 00:00:00 2001 From: Umesh Khatiwada Date: Tue, 7 Apr 2026 18:12:12 +0545 Subject: [PATCH] update(opensource):now 01cloud-backup is now opensource --- ABOUT.md | 103 ------------------------- RELEASES.md | 212 ---------------------------------------------------- 2 files changed, 315 deletions(-) delete mode 100644 ABOUT.md delete mode 100644 RELEASES.md diff --git a/ABOUT.md b/ABOUT.md deleted file mode 100644 index 2afc8d9..0000000 --- a/ABOUT.md +++ /dev/null @@ -1,103 +0,0 @@ -# About 01cloud-backup - -## Project Overview - -`01cloud-backup` is a production-ready gRPC microservice that simplifies Kubernetes backup and restore orchestration. Built for platform engineers and DevOps teams, it provides a clean, versioned API surface for backup automation without requiring direct coupling to Velero CLIs or Custom Resource Definitions. - -## Mission - -To make Kubernetes backup workflows programmatic, observable, and composable—enabling teams to build feature-rich backup platforms and control planes at any scale. - -## Why It Exists - -Velero is powerful but CLI-driven and stateless. Organizations building internal platforms, dashboards, or multi-tenant backup systems need: - -- **A persistent API** — gRPC service with lifecycle state tracking -- **Metadata management** — store backup labels, settings, and restore hints in a queryable database -- **Real-time notifications** — stream status updates without polling -- **Reproducible workflows** — save and reuse backup and restore configurations -- **Clean abstraction** — let platform teams own backup logic while users work through familiar UIs - -`01cloud-backup` fills that gap. - -## Architecture - -``` -┌─────────────────────────────────────────────────────────┐ -│ gRPC Client / Control Plane │ -└────────────────────┬────────────────────────────────────┘ - │ - v - ┌────────────────────────┐ - │ 01cloud-backup Service│ - │ (gRPC Server) │ - └────────────────────────┘ - / | \ - / | \ - v v v - Velero PostgreSQL WebSocket - CRDs (metadata) (status) -``` - -### Components - -- **gRPC API Layer** — handles backup lifecycle requests (create, list, detail, preserve, restore, delete) -- **Velero Integration** — translates API calls into Velero Backup, Restore, and Schedule CRD operations -- **PostgreSQL Backend** — persists backup metadata, labels, settings, and environment snapshots -- **WebSocket Server** — publishes real-time status updates to connected clients -- **Kubernetes Client** — queries cluster state and manages Velero resources - -## Core Features - -### Backup Lifecycle Management -- **Create** — initiate a new Velero-backed backup for a namespace or resource scope -- **List** — retrieve all backups with optional label and status filtering -- **Detail** — fetch comprehensive metadata including included resources and logs -- **Preserve** — mark backups to prevent automatic cleanup by retention policies -- **Restore** — trigger a restore from a named backup, with environment and add-on state replay -- **Delete** — remove a backup and associated metadata - -### Settings & Scheduling -- Save and reuse backup configurations per namespace -- Define cron-based backup schedules -- Persistent backup labels and metadata for retrieval and cost attribution - -### Real-Time Notifications -- WebSocket-based status streaming for zero-polling backup workflows -- Subscribe to backup and restore events as they occur - -### Restore Fidelity -- Capture environment snapshots at backup time to replay during restore -- Optionally restore application state alongside cluster workloads - -## Target Users - -- **Platform Engineers** building internal backup systems -- **DevOps Teams** automating Kubernetes backup workflows -- **SaaS Providers** offering backup-as-a-service to customers -- **Enterprise IT** managing backup compliance and retention policies - -## Technology Stack - -- **Language** — Go 1.20+ -- **API Protocol** — gRPC + Protocol Buffers -- **Database** — PostgreSQL -- **Kubernetes Integration** — client-go, Velero CRDs -- **Container Runtime** — Docker / OCI - -## Deployment Model - -Runs as a deployment or statefulset in your Kubernetes cluster. Communicates with Velero through the same cluster, requiring: -- Service account with permissions to read/write Velero CRDs -- Access to PostgreSQL (internal or external) -- Optional: WebSocket endpoint for status notifications - -## Open Source - -This project is licensed under the [Apache License 2.0](LICENSE). Contributions are welcome via pull requests. See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines and [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for community standards. - -## Getting Started - -For setup and usage instructions, refer to [README.md](README.md). -For development contribution details, see [CONTRIBUTING.md](CONTRIBUTING.md). -For security concerns, see [SECURITY.md](SECURITY.md). diff --git a/RELEASES.md b/RELEASES.md deleted file mode 100644 index 0296914..0000000 --- a/RELEASES.md +++ /dev/null @@ -1,212 +0,0 @@ -# Release Guide - -This document outlines the release process, versioning strategy, and procedures for publishing `01cloud-backup` releases. - -## Versioning - -We follow [Semantic Versioning](https://semver.org/): - -``` -MAJOR.MINOR.PATCH -``` - -- **MAJOR** — Incompatible API or data model changes -- **MINOR** — Backward-compatible feature additions -- **PATCH** — Backward-compatible bug fixes - -Examples: -- `1.0.0` — First stable release -- `1.1.0` — New feature, backward-compatible -- `1.1.1` — Bug fix -- `2.0.0` — Breaking API change - -## Release Schedule - -- **Regular releases** — typically every 4–6 weeks -- **Patch releases** — as-needed for critical bug fixes -- **Pre-releases** — alpha, beta, and release-candidate tags may be published for testing - -## Release Process - -### 1. Prepare Release Branch - -```bash -git checkout main -git pull origin main -git checkout -b release/v{VERSION} -``` - -Example: -```bash -git checkout -b release/v1.1.0 -``` - -### 2. Update Version References - -Update version info in: - -- **`CHANGELOG.md`** — Add a new section for the version with date and list of changes -- **`go.mod`** — Verify dependencies are up-to-date; run `go get -u` if needed -- **`Makefile`** — Update `VERSION` variable if needed - -Example CHANGELOG entry: - -```markdown -## [1.1.0] - 2026-04-15 - -### Added -- WebSocket health check endpoint -- Backup size metrics in metadata - -### Fixed -- Race condition in restore cleanup - -### Changed -- Improved error messages for invalid label queries - -[1.1.0]: https://github.com/berrybytes/01cloud-backup/releases/tag/v1.1.0 -[1.0.0]: https://github.com/berrybytes/01cloud-backup/releases/tag/v1.0.0 -``` - -### 3. Create Release Commit - -```bash -git add CHANGELOG.md go.mod Makefile -git commit -m "chore: release v{VERSION}" -``` - -### 4. Create Git Tag - -```bash -git tag -a v{VERSION} -m "Release v{VERSION}" -``` - -The tag triggers automated builds and release workflows. - -### 5. Push to Repository - -```bash -git push origin release/v{VERSION} -git push origin v{VERSION} -``` - -### 6. Create Pull Request - -Open a pull request on GitHub: - -- Title: `chore: release v{VERSION}` -- Description: Link to release notes or CHANGELOG section -- Merge strategy: Squash or standard merge (rebase not recommended) - -### 7. Merge to Main - -After CI passes and approval: - -```bash -git checkout main -git pull origin main -git merge release/v{VERSION} -git push origin main -``` - -### 8. Create GitHub Release - -On [GitHub Releases](https://github.com/berrybytes/01cloud-backup/releases): - -1. Click "Draft a new release" -2. Select the tag you created (`v{VERSION}`) -3. Title: `Release v{VERSION}` -4. Description: Copy from CHANGELOG for that version -5. Mark as pre-release if applicable -6. Publish - -This automatically triggers: -- Docker image build and push to container registry -- Binary artifact uploads -- Automated notifications - -## Artifact Publishing - -### Docker Images - -On tag push, GitHub Actions automatically builds and pushes Docker images: - -``` -gcr.io/zerone-devops-labs/01cloud-backup:v{VERSION} -gcr.io/zerone-devops-labs/01cloud-backup:latest -``` - -To manually build locally: - -```bash -docker build -t gcr.io/zerone-devops-labs/01cloud-backup:v{VERSION} . -docker push gcr.io/zerone-devops-labs/01cloud-backup:v{VERSION} -``` - -### Binary Artifacts - -Build binaries for distribution: - -```bash -make bin/01cloud-backup -# Output: ./bin/01cloud-backup-linux-amd64 -``` - -Upload to GitHub Release assets manually or via CI. - -## Pre-Release Versions - -For testing and community feedback, use pre-release tags: - -```bash -git tag -a v1.1.0-beta.1 -m "Beta release v1.1.0-beta.1" -git push origin v1.1.0-beta.1 -``` - -Pre-releases: -- Do not update the `latest` tag -- Are marked as pre-release on GitHub -- Are available for testing but not recommended for production - -## Rollback - -If a release has critical issues: - -1. **Create a patch release** on the previous version: - ```bash - git checkout v{PREVIOUS_VERSION} - git checkout -b hotfix/critical-fix - # Fix the issue, update CHANGELOG - git tag -a v{PREVIOUS_VERSION}.1 -m "Hotfix release" - ``` - -2. **Delete the broken release** from GitHub Releases - -3. **Soft-delete the tag** (optional): - ```bash - git tag -d v{VERSION} - git push origin :refs/tags/v{VERSION} - ``` - -## Maintenance & Support - -- **Current** — Latest released version receives all fixes and features -- **LTS (Long-term support)** — To be determined; older major versions may receive critical security patches only -- **End of Life** — Versions reach EOL after a new major version + 1 year; security issues may no longer be addressed - -## Release Checklist - -Before publishing: - -- [ ] All tests pass (`make qa`) -- [ ] Lint checks pass (`make lint`) -- [ ] CHANGELOG is updated with all changes -- [ ] Version numbers are consistent across files -- [ ] Documentation is current -- [ ] No hardcoded credentials or internal URLs -- [ ] Docker image builds successfully -- [ ] Git history is clean - -## Questions? - -For release-related questions or to propose release policy changes, open an issue or contact the maintainers at conduct@01cloud.io.