-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a Kapitan target per component #223
Comments
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 could also allow the removal of components further "down" the hierarchy by using the |
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. |
I'm not sure if there's anything special about the
|
Basically the idea boils down to having a separate data structure to define components which should be included (instead of using |
Turns out it needs to be called edit: hm, no maybe not, having a closer look. |
I also did a quick test with |
There's also some interesting (buggy?) behavior with regard to reclass's documented feature of prefixing entries in applications with a For example, with the following snippets, the final value of
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 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. |
With projectsyn/commodore#223 we're moving to using the reclass `applications` array to define which components are to be included, instead of directly including component classes in the hierarchy. Therefore the component needs to check in `inv.applications` instead of `inv.classes` whether synsights-metrics is enabled to decide whether to deploy the ArgoCD monitoring.
Implemented in #227. |
Context
We've found some instances (e.g. #156) where it would be beneficial to have a Kapitan target per component. For #156, having specific targets per component would allow us to reduce the amount of information that must be provided for the postprocessing filter definition (e.g. the component defining the filter would be clear based on the target).
There are some challenges in the implementation, if we want to make this change in a backwards-compatible manner. The current architecture relies on the single target Kapitan inventory for a number of features, the big ones being the dynamic hierarchy and component discovery. Additionally, some approaches for implementing this change would require refactoring all component classes.
Below we outline an approach which should be backwards compatible for the dynamic hierarchy and component discovery implementation, while not requiring any refactoring in the existing components.
Proposal
The best approach which doesn't require component refactoring and allows us to reuse the current implementation for the dynamic hierarchy and component discovery is to reorganize the Kapitan inventory slightly.
The new inventory structure will be constructed with empty files in
classes/components/
for each component. This way, the existing class includes of formcomponents.<component-name>
do not pull in the component class which has theparameters.kapitan
key anymore. The actual component classes will be made available inclasses/_components
(exact naming TBD).With this inventory structure, each target can have the dynamic hierarchy class include of
global.commodore
without defining compilation instructions for each component. Each target still needs to include all component default classes, to ensure all inventory references can be resolved. Additionally each target will need to include class_components.<component-name>
to pull in the Kapitan compile instructions for the targeted component.A target will have the following form:
Alternatives
An alternative approach which requires refactoring of all components would be to change components to define their Kapitan configuration in
parameters.<component-name>.kapitan
instead ofparameters.kapitan
. This allows us to continue using the component classes in the hierarchy exactly the same way as previously.Commodore could then generate individual targets per component where
parameters.kapitan
is extended as followsEach component is then responsible that their
parameters.<component-name>.kapitan
entry hasvars.target
set to<component-name>
.The text was updated successfully, but these errors were encountered: