Metadata-Version: 2.1
Name: nmanifest
Version: 0.0.2
Summary: Generate dynamic number of manifest repetitions using minimum configuration
Home-page: https://github.com/logiva/nmanifest
Author: Steffen Vinther Sørensen
Author-email: svs@logiva.dk
License: MIT
Description: # What is going on here ?
        
        This is to solve a problem where it is required to dynamically vary/repeat the number of generated manifests for each 
        of the otherwise quite similar dev, qa, staging, prod environments.
          
        An environment is usually a set of workloads, e.g microservices, e.g antivirus, ocr and other components that are
         able to scale horizontally and service the complete environment.
        But what if we for a given environment want to also run a n-times repeated set of "customer installation" sets as well. 
        
        As an example, we might need to run N instances of a legacy application server (HelmRelease), so we want to define this 
        helmrelease manifest just once, and then specify only the small configuration differences for each of needed instances.  
        
        This turns out to be an uneasy scenario to solve with Kustomize, because kustomizations is based on
        overlays that targets base manifests using specific (kind,namespace,name) coordinates, and for defining
        our N sets of "customer installations" we must vary the name part of the coordinates for each.
        
        
        # Managing a gitrepo for fluxd
        
        The repo structure is for the initial empty state
        
        ```
        └── releases
            |—— .flux.yaml 
        └── environments
        └── basetemplates
        ```
        
        The releases folder is meant to be configured as the fluxcd --git-path=releases argument 
        along with --manifest-generation=true
        
        The environments directory is to be populated with subdirectories defining an instance of our 
        workloads. Each subdirectory is to contain an editable copy of the root templates folder,
        and by editing these templates it will directly affect everything that is generator
        based on these templates.  
        
        The basetemplates folder is for base templates, editing these templates will only affect new
        instances, as nothing is directly generated from the base templates
        
        ## Populating the basetemplates
        
        The basetemplates are directories with sets of template files, e.g kubernetes yaml manifest files
        meant for jinja2 template processing
        
        e.g.
        ```
        └── basetemplates
            └── SET1
                |── template1.yaml
                |── template2.yaml
            └── SET2
                |── template1.yaml
                |── template2.yaml
        ```
        
        ## Create a new workload configuration in the environments folder
        
        An environment instance is expressed as subfolder in the environements folder, containing
        
        1. A snapshot copy of the basetemplates. E.g `cp -r basetemplates environments/NAME`
        2. folder `generatorconfigs` with the `.yaml` files with `generatorconfig` manifests  
        
        ```
        └── environments
            └── NAME
                └── templates
                    └── SET1
                        |── template1.yaml
                        |── template2.yaml
                    └── SET2
                        |── template1.yaml
                        |── template2.yaml
                └── generatorconfigs
                    |── SET1-a-generatorconfig.yaml
                    |── SET2-b-generatorconfig.yaml
                    |── SET2-c-generatorconfig.yaml
                    |── SET2-d-generatorconfig.yaml
        ```
                        
        # The `generatorconfig` format
        
        The format is meant to be basically just properties, meaning pure configuration without much structure structure.
        
        ```
        generatorconfigversion: 1
        templateset: SET2
        id: set2-a
        import_substitution_parameters:
          - set1
        substitution_parameters:
          NAME1: VALUE
          NAME2: VALUE
        overrides:
          - manifest:
              kind: MFKIND
              namespace: MFNAMESPACE
              name: MFNAME 
            values:
              PATH: OVERRIDE
        ```
        
        There are 2 mandatory parts:
        * generatorconfigversion : must be 1
        * templateset : pointer to template set directory for the environment, e.g SET2
        
        The rest is optional:
        * id: is optional, only useful if other generatorconfig needs to reference this config
        * import_substitution_parameters: List of generatorconfig ids to import substitution parameters from. 
        Each of the imported parameters can be overridden
        * substitution_parameters: is the parameters for jinja2 templating of the templates
        * overrides: Use it to override anything in the generated manifests. The section is a list with:
           * manifest: Optional if there is just 1 manifest in the template SET, otherwise the manifest (kind,namespace,name) coordinates
           * values: yaml to override anything in the jinja2 generated manifests
        
        
         
        
Platform: UNKNOWN
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Requires-Python: >=3.5
Description-Content-Type: text/markdown
