Metadata-Version: 2.4
Name: exordos_core
Version: 0.3.3
Summary: Exordos Core services
Author-email: Genesis Corporation <eugene@frolov.net.ru>
License: Apache-2.0
Project-URL: homepage, https://github.com/infraguys/exordos_core/
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: oslo.config<10.0.0,>=3.22.2
Requires-Dist: bjoern>=3.2.2
Requires-Dist: gcl_looper<2.0.0,>=1.2.3
Requires-Dist: restalchemy<17.0.0,>=16.1.2
Requires-Dist: Authlib<2.0.0,>=1.3.2
Requires-Dist: bazooka<2.0.0,>=1.3.0
Requires-Dist: Jinja2<4.0.0,>=3.1.5
Requires-Dist: izulu<1.0.0,>=0.50.0
Requires-Dist: gcl_iam<2.0.0,>=1.4.0
Requires-Dist: gcl_sdk[libvirt]<4.0.0,>=3.7.0
Requires-Dist: gcl_certbot_plugin<1.0.0,>=0.0.12
Requires-Dist: pyotp<3.0.0,>=2.9.0
Requires-Dist: pyyaml<7.0.0,>=6.0.0
Requires-Dist: netaddr<2.0.0,>=1.3.0
Requires-Dist: cryptography<47.0.0,>=45.0.5
Requires-Dist: firebase-admin<8.0.0,>=6.0.0
Requires-Dist: altcha<2.2.0,>=0.2.0
Requires-Dist: openapi-schema-validator>=0.8.1
Requires-Dist: packaging<=26.3,>=26.0
Provides-Extra: dev
Requires-Dist: tox>=4.0.0; extra == "dev"
Requires-Dist: tox-uv; extra == "dev"
Requires-Dist: pytest>=7.0.0; extra == "dev"
Provides-Extra: test
Requires-Dist: coverage>=4.0; extra == "test"
Requires-Dist: mock<6.0.0,>=3.0.5; extra == "test"
Requires-Dist: pytest<10.0.0,>=8.0.0; extra == "test"
Requires-Dist: pytest-xdist[psutil]<4.0.0,>=3.6.1; extra == "test"
Requires-Dist: pytest-timer<2.0.0,>=1.0.0; extra == "test"
Requires-Dist: dnspython<3.0.0,>=2.6.0; extra == "test"
Requires-Dist: ruamel-yaml==0.19.1; extra == "test"
Provides-Extra: mypy
Requires-Dist: mypy; extra == "mypy"
Provides-Extra: ruff
Requires-Dist: ruff<0.17.0,>=0.16.0; extra == "ruff"
Provides-Extra: shellcheck
Requires-Dist: shellcheck-py; extra == "shellcheck"
Provides-Extra: docs
Requires-Dist: zensical>=0.0.51; extra == "docs"
Requires-Dist: mkdocs-glightbox; extra == "docs"
Requires-Dist: mkdocs-render-swagger-plugin; extra == "docs"
Requires-Dist: mkdocs-static-i18n; extra == "docs"
Requires-Dist: ruamel-yaml==0.19.1; extra == "docs"

[![Tests](https://img.shields.io/github/actions/workflow/status/exordos/exordos_core/tests.yml?branch=master&label=tests&logo=github&style=flat-square)](https://github.com/exordos/exordos_core/actions/workflows/tests.yml)
[![Build](https://img.shields.io/github/actions/workflow/status/exordos/exordos_core/build.yml?branch=master&label=build&logo=github&style=flat-square)](https://github.com/exordos/exordos_core/actions/workflows/build.yml)
[![Python](https://img.shields.io/badge/python-3.10%20%7C%203.11%20%7C%203.12%20%7C%203.13%20%7C%203.14-3776AB?logo=python&logoColor=white&style=flat-square)](https://www.python.org/)
[![uv](https://img.shields.io/badge/uv-managed-DE5FE9?logo=uv&logoColor=white&style=flat-square)](https://github.com/astral-sh/uv)
[![Code style: ruff](https://img.shields.io/badge/code%20style-ruff-D7FF64?logo=ruff&logoColor=black&style=flat-square)](https://github.com/astral-sh/ruff)
[![License: Apache 2.0](https://img.shields.io/badge/license-Apache%202.0-blue?style=flat-square)](https://www.apache.org/licenses/LICENSE-2.0)

<p align="center">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="logo_black.svg">
    <source media="(prefers-color-scheme: light)" srcset="logo_white.svg">
    <img height="256" src="logo_white.svg" alt="exordos core svg logo">
  </picture>
</p>

# Exordos Core

**📚 Documentation:** [exordos.github.io/exordos_core](https://exordos.github.io/exordos_core/)

Exordos Core is an open-source NoOps platform for managing corporate infrastructure and software ecosystems. It provides a unified platform layer — from bare metal and virtual machines all the way to applications and services — designed to be operated by both humans and AI agents.

## What Exordos Core does

Exordos Core is the next step beyond classic DevOps. Instead of a collection of disconnected tools requiring constant manual coordination, it gives your organization a single declarative platform layer where infrastructure, policies, and service lifecycle are managed as one coherent system.

Key capabilities:

- **Declarative management** — describe the desired state; the platform reconciles reality to match it automatically (self-healing). No more configuration drift or manual correction after every change.
- **Image-based provisioning** — fast, repeatable, and predictable delivery of environments and services. Rollouts and recovery become straightforward operations, not fire-fighting exercises.
- **AI-ready architecture** — the platform is designed from the ground up to be controlled by an AI agent, reducing manual toil and letting teams operate at the level of intent rather than low-level steps. An [MCP server](https://exordos.github.io/exordos_core/usage/mcp/) runs alongside the User API for agents to connect to directly.
- **Unified lifecycle management** — infrastructure, internal services, and application lifecycle all managed through a single control plane. One system instead of a zoo of tools.
- **Sovereign deployment** — run entirely within your own on-prem or private cloud perimeter with no dependency on external services. Full control over data, access, and the operational boundary.
- **Element ecosystem** — install and manage ready-to-use software elements (databases, messengers, internal services, and more) directly from the platform marketplace, just like an app store for enterprise software.

> **For a full overview of architecture, configuration, and advanced usage, visit the [documentation](https://exordos.github.io/exordos_core/).**

# 🚀 To start using Exordos

Install the CLI tools with a single command:

```bash
curl -fsSL https://repo.exordos.com/install.sh | sudo sh
```

Then follow the instructions in the terminal, or refer to the [documentation](https://exordos.github.io/exordos_core/) for a full setup guide.

# 💡 Contributing

Contributing to the project is highly appreciated! However, some rules should be followed for successful inclusion of new changes in the project:

- All changes should be done in a separate branch.
- Changes should include not only new functionality or bug fixes, but also tests for the new code.
- After the changes are completed and **tested**, a Pull Request should be created with a clear description of the new functionality. And add one of the project maintainers as a reviewer.
- Changes can be merged only after receiving an approve from one of the project maintainers.

## Disk placement

Disk specifications and standalone volumes accept `tier` (`COLD`, `WARM`,
`HOT`) and `ephemeral` (`true` or `false`). Both default to `WARM`/`true`,
which identifies local qcow2 storage. The scheduler prefers an exact tier
match and falls back to another tier with enough space, while always
preserving `ephemeral`. Persistent disks must request `ephemeral: false`.

The chosen storage pool is retained for reuse and resize; an existing disk
is never moved merely because another pool has more free space. Changing
`tier` or `ephemeral` after creation is unsupported.

This branch requires the matching `gcl_sdk` branch `feat/disk-scheduling`
(PR #211) before it can be merged and released. The SDK must provide
`DiskTier`, the disk policy fields, and `select_storage_pool`; a released
SDK without these APIs is insufficient.

Until that SDK release is published, `uv.lock` pins the development SDK
commit `2987730b84e090666ecf46b64a6e6cecdfaf1872` through `tool.uv.sources`.
This makes `uv sync --locked` reproducible without resolving an older SDK
from PyPI. Image builds can still use `LOCAL_GENESIS_SDK_PATH`.

The disk scheduling migration also converts existing local hypervisor driver
configuration to the list-of-pools schema. Update the CLI together with the
SDK and core so new hypervisor registrations use that schema too.

Disk policy changes on existing node disks are rejected before persisting API
or manifest updates. Resizing a disk with its existing policy remains supported.
The curated MCP node tools expose `tier` and `ephemeral` too.

The disk scheduling JSON migration supports downgrade: it removes the added
policy fields, restores single local-pool names, and invalidates resource hashes
for rebuilding by the previous release. A local hypervisor with multiple pools
cannot be represented by the old schema; downgrade refuses that configuration
rather than silently discarding pool assignments.
