Platform Engine Modules

The dettonville.engine collection provides the runtime abstraction layers necessary to deliver unified developer platforms and automation runtimes without public cloud control structures. These modules provision isolated container spaces, local binary endpoints, and highly optimized hardware computing resources for artificial intelligence workflows.

Module Inventory & Parameter Specifications

1. Isolated Container Runtimes (engine_container_stack)

Installs and stabilizes upstream container engines and local execution namespaces, isolating virtual process loops while strictly blocking external runtime socket exposure.

• Primary Variables:
  • engine_container_runtime: The target orchestration daemon (standardized on upstream open-source docker-ce or podman).
  • engine_container_storage_driver: The localized storage mapping backend (defaulting to performance-tuned overlay2).
  • engine_container_bip: A strict, non-overlapping internal private IPv4 bridge CIDR block definition.
• DRY Execution Strategy: A generic systemd layout template handles container daemon instantiation across all platforms. Node variations (like host-specific internal networking constraints) are dynamically parsed from centralized group asset maps.

2. Local Supply-Chain Registries (engine_local_mirror)

Deploys local caching registries and proxy engines to establish complete organizational custody over software binaries, packages, and images.

• Primary Variables:
  • engine_mirror_types: Array identifying target registries to back locally (e.g., container, python_pip, rpm_rocky).
  • engine_mirror_storage_path: The persistent local storage mount mapping where cached blobs and binary archives reside.
• Idempotent State Rule: The module continuously validates proxy routing tables. If internal resolution modifications bypass the local storage mirror paths, the framework rewrites the lookup paths back to the local perimeter.

3. Localized Inference Foundations (engine_ai_inference)

Orchestrates hardware-accelerated processing layers, host GPU drivers, and local artificial intelligence execution blocks within automation constraints.

• Primary Variables:
  • engine_ai_framework: The chosen local inference host controller (standardized on community-optimized engines like ollama or native vllm stacks).
  • engine_ai_hardware_acceleration: Defines the explicit compute toolkit profile (e.g., cuda or rocm).
  • engine_ai_model_manifest: A flat-file list mapping specific model weights to their verified internal storage paths and SHA-256 integrity tags.

Sample Integration Manifest

To bundle these platform primitives into a single localized runtime track, define the variables inside your versioned YAML configuration:

- name: Stand Up Off-Grid Developer Platform Engine
  hosts: runtime_clusters
  gather_facts: true
  vars:
    engine_container_runtime: "docker-ce"
    engine_container_bip: "172.24.10.1/24"
    engine_mirror_types:
      - "container"
      - "python_pip"
    engine_ai_framework: "ollama"
    engine_ai_hardware_acceleration: "cuda"
    engine_ai_model_manifest:
      - name: "llama3:8b-instruct-q8_0"
        path: "/opt/ai/models/llama3-8b.gguf"

  roles:
    - role: dettonville.engine.container_stack
    - role: dettonville.engine.local_mirror
    - role: dettonville.engine.ai_inference

Technical Flow and Audit Output

Every pass across the engine orchestration library reports state output changes into flat, human-readable text schemas to protect visibility over local runtime states:

1. Pre-Flight Inspection: Evaluates the presence of base kernel storage backends and validates GPU hardware availability.
2. Deterministic Layout Application: Configures system runtime units, applies proxy rules, and drops static local configurations into system files.
3. State Drop affirmation: Writes structured execution feedback straight into /var/log/dettonville/engine_runtime.json for validation at local administrative terminals.