Define a Kapitan target per component about commodore HOT 8 CLOSED

I'm not sure if there's anything special about the applications array. We could also call it components for example:

classes:
- cloud.cloudscale

components:
- csi-cloudscale

parameters:
   csi_cloudscale:
    some: value

from commodore.

There's also some interesting (buggy?) behavior with regard to reclass's documented feature of prefixing entries in applications with a ~: due to the way the recursive processing of the applications field is managed, dropping entries doesn't always work.

For example, with the following snippets, the final value of applications for targets/test.yml is ["argocd", "resource-locker", "steward", "storageclass"].

# targets/test.yml
classes:
  - global.kubernetes
  - tenant.cluster

# global/kubernetes.yml
applications:
- argocd
- resource-locker
- steward
- storageclass

# tenant/cluster.yml
applications:
- ~storageclass

I've spent a good amount of time investigating this issue in reclass, and have found the cause in https://github.com/projectsyn/reclass/blob/2585bfc620ddd8c2cd7d159c4eb6d117a526a819/reclass/core.py#L148-L159, where the calls to _recurse_entity while processing the entries in classes are passed merge_base=None, which has the effect that the applications field is processed in isolation for each class included in the same file (class or target). Since entries prefixed with ~ in applications are not preserved across calls, but immediately resolved during the calls to merge_base.merge(), we get the behavior outlined above.

The fix appears to be to change the linked snippet to the version present in https://github.com/projectsyn/reclass/tree/fix/application-removal. Note that this change needs kapicorp/reclass#4 to be merged to work correctly.

from commodore.

Reclass also has the concept of aplications (basically a list of strings?). Maybe we can use this to specify the components to include in the hierarchy? (To prevent creating these empty class files).
This would require a refactoring of the whole inventory and moving the components.$component_name includes to the applications: array.

This could also allow the removal of components further "down" the hierarchy by using the ~ prefix in the applications array (xref #71 ).

from commodore.

Thanks for the hint about applications, I'll have a look at those as well. Looks like that approach might work for component includes in the hierarchy.

from commodore.

Basically the idea boils down to having a separate data structure to define components which should be included (instead of using classes: directly) and having Commodore generate the appropriate class includes for each component.

from commodore.

I'm not sure if there's anything special about the applications array. We could also call it components for example:

Turns out it needs to be called applications for the reclass magic to work, cf. https://github.com/kapicorp/reclass/blob/1869c478624b37d3479d6c4ea4769dc9ec41fadd/reclass/core.py#L253-L284

edit: hm, no maybe not, having a closer look.

from commodore.

I also did a quick test with components but this (obviously in hindsight) doesn't work since only things in classes, applications and parameters are merged together (the rest is dropped).

from commodore.

Implemented in #227.

from commodore.