Skip to content

Define a standard kdevops module layout and migrate #62

@dkruces

Description

@dkruces

Problem

kdevops modules today consist of multiple components: Ansible playbooks, Ansible roles, Kconfig files, and Makefile files. However, there is no standardized or documented module structure, and modules place their files in inconsistent locations.

This creates confusion for adding or extending modules and/or automated tooling or AI that rely on predictiable patterns.

For example, the ansible_cfg module is formed by:

  • ./playbooks/roles/ansible_cfg/*
  • ./playbooks/ansible_cfg.yml
  • ./kconfigs/Kconfig.ansible_cfg
  • ./Makefile

Another example:

  • ./playbooks/build_qemu.yml
  • ./Makefile.build_qemu
  • ./playbooks/roles/build_qemu
  • kconfigs/Kconfig.libvirt

The lack of a well-defined structure makes it unclear what files constitute a module and where new module components should be placed.

Task

  1. Review current kdevops module patterns and establish a new directory structure. Review workflows/ as well as scripts/, playbooks/ and kconfigs/ directories. Shall we keep/reorganize the way Kconfig menu is displayed? Do we need kdevops modules and submodules? e.g. libvirt module and largeio submodule?

  2. Define and document what a “kdevops module” is, including:

  • Required components (Role, Playbook, Kconfig, Makefile fragment).
  • Naming conventions.
  • Directory structure.
  • How output yaml export integrates with modules.
  1. Create an official recommended directory structure for all modules.
    Example structure (to be refined during design):
    playbooks/<module>.yml
    playbooks/roles/<module>/
    kconfigs/Kconfig.<module>
    makefiles/Makefile.<module>

  2. Audit all existing modules, map them to the new structure, and migrate them. Ensure documentation is updated to reflect the new module standard.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions