ansible-ds Design


General considerations


Note: I do not describe the ansible variable in this document because they are precisely described in the ansible collection Readme

Existing works about 389ds over ansible

Other ansible work over 389ds

Considered alternatives:

Test strategy


Automated tests are based on pytest framework that run:

General architecture


The ansible is delivered as a galaxy ansible collection

named ds/ansible-ds (TBC as I need to rbe able to register the “DS” name )

The collection consist in a set of:

The typical workflow is a playbook that use roles that interfaces plugins that import utilities modules.

plugin architecture


utilities modules

An utility module is a python library used by other plugins.

dsutil

Goal

Provides some common tools:

dsentities

Goal

Provides the code needed to:

Architecture

dsentities_options

Goal

This module provides the specification of ansible parameter associated with the entities

Architecture

This module is generated from the dsentities module by: python utils/gendoc.py spec command.

It generates a CONTENT_OPTIONS variable containing the argument specification for the entities module using the format specified in

Ansible module architecture — Ansible Documentation

This variable is then used by ds_server module to parse the ansible variables.

plugins

ds_server plugin

Goal

update ds configuration. It allows to:

Architecture

This module is derivated from Ansible module example and: using dsentities_options as parameter spec to parse the ansible parameters creates a dsentities.YAMLRoot instance from these parameters calls the YAMLRoot.update method format the result

Last modified on 1 July 2022