diff --git a/docs/.vitepress/config.mts b/docs/.vitepress/config.mts index fad3a03..b14f427 100644 --- a/docs/.vitepress/config.mts +++ b/docs/.vitepress/config.mts @@ -25,6 +25,28 @@ function storageSidebar() { }; } +function overviewSidebar() { + const generated = generateSidebar([{ + documentRootPath: '/docs/', + scanStartPath: 'overview', + resolvePath: '/overview/', + capitalizeFirst: false, + useTitleFromFrontmatter: true, + useFolderLinkFromIndexFile: true, + useFolderTitleFromIndexFile: true, + sortMenusByFrontmatterOrder: true, + }]); + const items = generated['/overview/'].items.filter((i: any) => i.link !== 'index.md'); + const showroomEntry = { text: 'Showroom', link: 'showroom/', base: '/' }; + const overviewItems = [ + { text: 'About CobaltCore', items: [{ text: 'Overview', link: '/overview/' }, ...items.map((i: any) => ({ ...i, link: '/overview/' + i.link })), showroomEntry] }, + ]; + return { + '/overview/': { items: overviewItems }, + '/showroom/': { items: overviewItems }, + }; +} + function observabilitySidebar() { const generated = generateSidebar([{ documentRootPath: '/docs/', @@ -83,7 +105,7 @@ export default withMermaid({ // https://vitepress.dev/reference/default-theme-config nav: [ { text: 'Home', link: '/' }, - { text: 'Overview', link: '/overview/' }, + { text: 'About CobaltCore', link: '/overview/' }, { text: 'Getting Started', link: '/getting-started/' }, { text: 'Documentation', @@ -135,16 +157,6 @@ export default withMermaid({ useFolderTitleFromIndexFile: true, sortMenusByFrontmatterOrder: true, }, - { - documentRootPath: '/docs/', - scanStartPath: 'overview', - resolvePath: '/overview/', - capitalizeFirst: false, - useTitleFromFrontmatter: true, - useFolderLinkFromIndexFile: true, - useFolderTitleFromIndexFile: true, - sortMenusByFrontmatterOrder: true, - }, { documentRootPath: '/docs/', scanStartPath: 'getting-started', @@ -185,16 +197,6 @@ export default withMermaid({ useFolderTitleFromIndexFile: true, sortMenusByFrontmatterOrder: true, }, - { - documentRootPath: '/docs/', - scanStartPath: 'blog', - resolvePath: '/blog/', - capitalizeFirst: false, - useTitleFromFrontmatter: true, - useFolderLinkFromIndexFile: true, - useFolderTitleFromIndexFile: true, - sortMenusByFrontmatterOrder: true, - }, { documentRootPath: '/docs/', scanStartPath: 'community', @@ -218,6 +220,7 @@ export default withMermaid({ ]), ...storageSidebar(), ...observabilitySidebar(), + ...overviewSidebar(), }, socialLinks: [ diff --git a/docs/.vitepress/theme/components/BlogPost.vue b/docs/.vitepress/theme/components/BlogPost.vue new file mode 100644 index 0000000..66218ef --- /dev/null +++ b/docs/.vitepress/theme/components/BlogPost.vue @@ -0,0 +1,54 @@ + + + + + diff --git a/docs/.vitepress/theme/index.js b/docs/.vitepress/theme/index.js index a9319cb..8928635 100644 --- a/docs/.vitepress/theme/index.js +++ b/docs/.vitepress/theme/index.js @@ -1,8 +1,12 @@ import DefaultTheme from 'vitepress/theme' import Layout from './components/Layout.vue' +import BlogPost from './components/BlogPost.vue' import './custom.css' export default { extends: DefaultTheme, Layout, + enhanceApp({ app }) { + app.component('BlogPost', BlogPost) + }, } diff --git a/docs/blog/index.md b/docs/blog/index.md index c66f496..a14cb0d 100644 --- a/docs/blog/index.md +++ b/docs/blog/index.md @@ -1,12 +1,12 @@ --- title: Blog -order: 1 --- # Blog -News, talks, and deep-dives from the CobaltCore project. - -## Posts - -- [Bridging CNCF and OpenInfra: Kubernetes as the Unified Control Plane for Sovereign Cloud](./bridging-cncf-openinfra-kubernetes-control-plane) + diff --git a/docs/community/index.md b/docs/community/index.md index c093bf7..9fbfcd7 100644 --- a/docs/community/index.md +++ b/docs/community/index.md @@ -2,131 +2,4 @@ title: Community --- -
-

Join the CobaltCore Community

-

CobaltCore is an open source project built by operators, for operators. Whether you want to ask a question, report a bug, contribute code, or help shape the project's direction - you're welcome here.

-
- -## Get connected - -
-
-
๐Ÿ’ฌ
-

GitHub Discussions

-

Ask questions, share ideas, and discuss CobaltCore with maintainers and other community members.

- Open a discussion โ†’ -
-
-
๐Ÿ›
-

Issues & Roadmap

-

Browse open issues, report bugs, request features, and track what's being worked on.

- Browse issues โ†’ -
-
-
๐Ÿ“‹
-

Community Meetings

-

Regular community meetings to discuss development, proposals, and the project roadmap. All are welcome.

- See discussions โ†’ -
-
- -## Contribute - -CobaltCore welcomes contributions of all kinds - code, documentation, bug reports, and feedback. - -### Before you start - -- **Open an issue first** for any non-trivial change. Describe the problem or enhancement and indicate you'd like to work on it. The team will review and assign it if it's a good fit. -- **Claim existing issues** by commenting on them to avoid duplicated effort. - -### How to contribute - -1. Fork the relevant repository under [github.com/cobaltcore-dev](https://github.com/cobaltcore-dev) -2. Create a branch for your change -3. Submit a pull request - a maintainer will review it -4. Sign off your commits with a [Developer Certificate of Origin (DCO)](https://developercertificate.org/) - -All contributions must be licensed under [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0). - -For full contribution guidelines, see [CONTRIBUTING.md](https://github.com/cobaltcore-dev/docs/blob/main/CONTRIBUTING.md). - -### Contributing to docs - -The documentation lives in [github.com/cobaltcore-dev/docs](https://github.com/cobaltcore-dev/docs). Every page has an **Edit this page on GitHub** link at the bottom - the quickest way to suggest a fix or improvement. - -## Code of Conduct - -CobaltCore follows the [SAP Open Source Code of Conduct](https://github.com/SAP/.github/blob/main/CODE_OF_CONDUCT.md). We are committed to a welcoming and inclusive environment for everyone. To report instances of unacceptable behavior, please follow the reporting process described in the Code of Conduct. - -## Governance - -CobaltCore is a [Linux Foundation Europe](https://linuxfoundation.eu) project, co-funded by the European Union through the NextGenerationEU programme. - - +# Community diff --git a/docs/overview/architecture.md b/docs/overview/architecture.md index 52378f0..160e8c5 100644 --- a/docs/overview/architecture.md +++ b/docs/overview/architecture.md @@ -6,8 +6,6 @@ outline: deep # Architecture -CobaltCore is organized as a layered stack. Each layer has a clear responsibility and depends only on the layers beneath it. - ``` โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”‚ Management Aurora ยท Greenhouse ยท Cortex โ”‚ @@ -28,50 +26,16 @@ CobaltCore is organized as a layered stack. Each layer has a clear responsibilit ## Platform -The foundation. Kubernetes provides the control plane. IronCore handles bare metal discovery and lifecycle. Gardener manages cluster lifecycle (creating, upgrading, and deleting Kubernetes clusters). GardenLinux is the hardened Linux OS that runs on hypervisor nodes. - -Everything above this layer runs as Kubernetes workloads. - ## Compute, Storage, Networking -The infrastructure data plane - the raw execution environment for virtual machines and cloud services. - -- **[Compute](/compute/)** - KVM hypervisors managed by a Kubernetes operator. VMs run on bare metal nodes via libvirt. The HA service monitors hypervisor health and triggers evacuation when nodes fail. -- **[Storage](/storage/)** - Ceph provides block (RBD), object (RGW), and file (CephFS) storage. Rook operates Ceph as a Kubernetes-native workload. Arbiter enables stretched clusters across two data centers. Chorus handles S3 object replication. -- **[Networking](/network/)** - OVN provides virtual networking for VMs. Neutron's OVN integration manages the control plane. +- **[Compute](/compute/)** +- **[Storage](/storage/)** +- **[Networking](/network/)** ## Observability -Cross-cutting. [Prysm](/observability/prysm) collects audit and operational -events. [Prometheus](/observability/prometheus) scrapes metrics from all -layers. [Perses](/observability/perses) provides dashboards. - ## OpenStack -The cloud services layer. OpenStack APIs (Nova, Neutron, Cinder, Keystone, Glance) are deployed via Helm and connect to the compute, storage, and networking layers below. Users and applications interact with CobaltCore primarily through OpenStack APIs. - ## Management -The operations and control plane UI. Aurora is the cloud management frontend. Greenhouse provides the monitoring and management umbrella. Cortex handles intelligent placement and scheduling of workloads across the cluster. - ## Data flow: provisioning a VM - -To ground the architecture, here is the path a VM takes from API call to running workload: - -```mermaid -sequenceDiagram - participant User - participant Nova as OpenStack Nova - participant Cortex as Cortex (placement) - participant Hypervisor as KVM Hypervisor - participant Ceph as Ceph (storage) - participant OVN as OVN (networking) - - User->>Nova: Create VM request - Nova->>Cortex: Request placement decision - Cortex-->>Nova: Target hypervisor node - Nova->>Hypervisor: Spawn VM via libvirt - Nova->>Ceph: Attach RBD volume - Nova->>OVN: Wire VM network port - Hypervisor-->>User: VM running -``` diff --git a/docs/overview/index.md b/docs/overview/index.md index a673e77..8812447 100644 --- a/docs/overview/index.md +++ b/docs/overview/index.md @@ -5,35 +5,9 @@ order: 1 # What is CobaltCore? -CobaltCore is an open source, opinionated OpenStack distribution built on Kubernetes. It brings cloud-native operations to traditional, non-containerized workloads - giving operators the automation, resilience, and observability of a modern platform without requiring their applications to change. - -At its core, CobaltCore assembles proven open source technologies - Kubernetes, OpenStack, Ceph, OVN - into a coherent, production-ready distribution with a clear operational model. Instead of assembling and integrating these components yourself, you get a tested stack with sensible defaults, lifecycle management, and a consistent control plane. - -## Who it's for - -CobaltCore is for teams that: - -- Run KVM-based virtual machines at scale and need automated provisioning, evacuation, and failover -- Want OpenStack's cloud APIs (Nova, Neutron, Cinder) managed declaratively through Kubernetes operators -- Need distributed Ceph storage with high availability across failure domains -- Are adopting Kubernetes as a foundation but still need to support traditional VM workloads - -## Key capabilities - -| Capability | How CobaltCore delivers it | -|---|---| -| Server discovery and provisioning | IronCore manages bare metal lifecycle; GardenLinux is deployed as the hypervisor OS | -| KVM hypervisor management | Kubernetes operators control hypervisor configuration, upgrades, and health | -| High availability for VMs | HA service monitors hypervisor health and triggers live migration or evacuation automatically | -| OpenStack cloud APIs | Nova, Neutron, Cinder, Keystone, and Glance deployed and managed via Helm | -| Distributed storage | Ceph managed by Rook, with Arbiter for stretched-cluster quorum | -| Observability | Prysm, Prometheus, and Perses provide metrics, alerting, and dashboards | -| Management UI | Aurora provides a cloud management frontend; Greenhouse is the monitoring umbrella | - ## How to navigate these docs - **[Getting Started](/getting-started/)** - start here if you want to deploy CobaltCore - **[Architecture](/overview/architecture)** - understand how the layers fit together -- **[Why CobaltCore](/overview/why)** - the reasoning behind the design decisions - **[Showroom](/showroom/)** - live examples and demos of CobaltCore in action - Layer sections (**Platform**, **Compute**, **OpenStack**, **Storage**, **Networking**, **Observability**, **Management**) - deep-dive reference for each part of the stack. diff --git a/docs/overview/why.md b/docs/overview/why.md deleted file mode 100644 index 0076ecf..0000000 --- a/docs/overview/why.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Why CobaltCore? -order: 3 ---- - -# Why CobaltCore? - -## The problem: traditional workloads in a cloud-native world - -Most cloud infrastructure projects today focus on containerized workloads. But a large portion of real-world applications - databases, legacy enterprise software, latency-sensitive services - run as virtual machines and are not practical to containerize. - -The standard options have real tradeoffs: - -- **Public cloud** - operational simplicity but loss of control, unpredictable cost at scale, data sovereignty concerns -- **Vanilla OpenStack** - full control but operationally complex, hard to automate, no native Kubernetes integration -- **DIY Kubernetes + VMs** - possible with KubeVirt and similar projects, but lacks the mature cloud API layer (Nova, Neutron, Cinder) that operations teams and their automation tools already depend on - -CobaltCore is built for teams that need the cloud API familiarity of OpenStack, the operational automation of Kubernetes, and the control of running their own infrastructure. - -## Why Kubernetes as the foundation? - -Kubernetes provides a declarative, self-healing control plane. Running OpenStack components as Kubernetes workloads means: - -- Operators can express desired state for hypervisors, storage clusters, and network configurations as Kubernetes resources -- Standard Kubernetes tooling (Helm, operators, RBAC, GitOps) applies to infrastructure management -- The cluster lifecycle itself (creation, upgrades, scaling) is managed by Gardener, which is also Kubernetes-native - -## Why OpenStack? - -OpenStack provides mature, well-understood cloud APIs that operator tooling, internal platforms, and users already know. Nova, Neutron, and Cinder are stable interfaces with broad ecosystem support - tooling, SDKs, and automation built against these APIs does not need to change. - -CobaltCore does not replace OpenStack. It makes OpenStack easier to run by managing it through Kubernetes operators and Helm, and by integrating it tightly with the storage and networking layers. - -## Why Ceph? - -Ceph is the only open source storage system that provides block, object, and file storage from a single unified cluster. For a cloud distribution, this matters: Nova uses RBD for VM disks, applications use RGW for object storage, and shared workloads use CephFS - all from one storage pool with consistent replication, access control, and observability. - -Rook extends this by making Ceph a first-class Kubernetes workload, enabling declarative cluster management and automated remediation. - -## Why OVN for networking? - -OVN (Open Virtual Network) replaces the legacy Open vSwitch agent-per-node model with a centralized control plane and distributed forwarding. This means: - -- Network state is managed consistently from a single source of truth (OVN Northbound DB) -- Fewer moving parts on each compute node -- Better scalability at large node counts - -Neutron's OVN integration is now the recommended path for production OpenStack deployments. - -## Design principles - -1. **Prefer operators over runbooks.** Routine operations (node evacuation, storage rebalancing, certificate rotation) should be automated by operators, not manual procedures. -2. **Declarative over imperative.** Infrastructure state is expressed as Kubernetes resources, not scripts. -3. **Integrate, don't replace.** OpenStack, Ceph, and OVN are mature projects with large communities. CobaltCore integrates them rather than reimplementing their functionality. -4. **Open and composable.** Each layer can be understood and operated independently. You are not locked into a proprietary control plane.