-
Notifications
You must be signed in to change notification settings - Fork 107
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
feat: refactor manifest handling #867
feat: refactor manifest handling #867
Conversation
add process unit tests, move apply() logic back to feature add given when then apply and process manifests in one step in Feature.Apply() move feature tracker out of spec add targetNamespace to feature, label+ns setting in kustomize manifest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This very nice improvement. I shared a few suggestions, but other than that solid work!
Thanks for expanding tests!
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
let k8s handle it
@bartoszmajsak re-tested e2e on crc after resolving merge conflicts + addressing review. Re-requesting review now when you have time 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few small nits, last round :)
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Hi @zdtsw, removed the |
sorry, did not get back to you asap. looks good for me and thanks for the hard (rebase) work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
would be good to merge incubation
back so the tests will run and then squash merge PR.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bartoszmajsak, zdtsw The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
New changes are detected. LGTM label has been removed. |
/test opendatahub-operator-e2e |
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com> Reworks the way that the `Feature` framework creates and handles manifests. Rather than treat all manifests as one type with flags for how it should be treated, we now define Manifest as an interface, and add the `BaseManifest`, `TemplateManifest`, and `KustomizeManifest` types - adding initial support for Kustomization files. Also, this PR adds the `TargetNamespace` field to Feature.spec, allowing users to specify a TargetNamespace for their kustomization manifests to be applied to. - `BaseManifest`s are created for processing raw yaml files - no templating needed, just apply yaml to create objects. - `TemplateManifest`s are created for processing .tmpl files - templating is applied to these files (substituting values within file). Both of these support .patch files. - `KustomizeManifest`s are created for processing `kustomization.yaml` files (also supports passing in the directory that contains said file). This allows for better processing of each type of manifest - now the process() method returns a list of unstructured objects to be applied rather than storing strings within the manifest type. Note that `KustomizeManifest`'s only support files stored within the filesystem - not the embedded filesystem. e.g. it supports files stored in `/opt/manifests/...`.
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com> Reworks the way that the `Feature` framework creates and handles manifests. Rather than treat all manifests as one type with flags for how it should be treated, we now define Manifest as an interface, and add the `BaseManifest`, `TemplateManifest`, and `KustomizeManifest` types - adding initial support for Kustomization files. Also, this PR adds the `TargetNamespace` field to Feature.spec, allowing users to specify a TargetNamespace for their kustomization manifests to be applied to. - `BaseManifest`s are created for processing raw yaml files - no templating needed, just apply yaml to create objects. - `TemplateManifest`s are created for processing .tmpl files - templating is applied to these files (substituting values within file). Both of these support .patch files. - `KustomizeManifest`s are created for processing `kustomization.yaml` files (also supports passing in the directory that contains said file). This allows for better processing of each type of manifest - now the process() method returns a list of unstructured objects to be applied rather than storing strings within the manifest type. Note that `KustomizeManifest`'s only support files stored within the filesystem - not the embedded filesystem. e.g. it supports files stored in `/opt/manifests/...`. (cherry picked from commit ec81ef6)
https://issues.redhat.com/browse/RHOAIENG-3262
Description
The is PR reworks the way that the
Feature
framework creates and handles manifests. Rather than treat all manifests as one type with flags for how it should be treated, we now define Manifest as an interface, and add theBaseManifest
,TemplateManifest
, andKustomizeManifest
types - adding initial support for Kustomization files. Also, this PR adds theTargetNamespace
field to Feature.spec, allowing users to specify a TargetNamespace for their kustomization manifests to be applied to.BaseManifest
s are created for processing raw yaml files - no templating needed, just apply yaml to create objects.TemplateManifest
s are created for processing .tmpl files - templating is applied to these files (substituting values within file).Both of these support .patch files.
KustomizeManifest
s are created for processingkustomization.yaml
files (also supports passing in the directory that contains said file).This allows for better processing of each type of manifest - now the process() method returns a list of unstructured objects to be applied rather than storing strings within the manifest type.
Note that KustomizeManifest's only support files stored within the filesystem - not the embedded filesystem. eg it supports files stored in
opt/manifests/...
.How Has This Been Tested?
Added new unit tests for each type's Process() method - added the path to this to
make unit-test
. Also added another feature integration test for a KustomizeManifest.For testing manually, built image
quay.io/cgarriso/opendatahub-operator:dev-split-manifest-types
and ensured features within DSCI's service mesh setup still worked as expected. Also, in this image I created some 'fake' features:ensuring that KustomizeManifest's with a TargetNamespace worked as expected on CRC.
Merge criteria: