Skip to content
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

Conversation

cam-garrison
Copy link
Contributor

@cam-garrison cam-garrison commented Feb 15, 2024

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 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.

  • BaseManifests are created for processing raw yaml files - no templating needed, just apply yaml to create objects.
  • TemplateManifests are created for processing .tmpl files - templating is applied to these files (substituting values within file).
    Both of these support .patch files.
  • KustomizeManifests 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. 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:

createKustTwoErr := feature.CreateFeature("create-kustomization-two").
    For(handler).
    Manifests(path.Join("opt", "manifests", "fake-kust-dir")).
    TargetNamespace("istio-system").
    Load()

ensuring that KustomizeManifest's with a TargetNamespace worked as expected on CRC.

Merge criteria:

  • The commits are squashed in a cohesive manner and have meaningful messages.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

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
Copy link
Contributor

@bartoszmajsak bartoszmajsak left a 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!

pkg/feature/builder.go Outdated Show resolved Hide resolved
pkg/feature/builder.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/feature.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/raw_resources.go Outdated Show resolved Hide resolved
cam-garrison and others added 15 commits February 15, 2024 16:01
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>
@cam-garrison
Copy link
Contributor Author

@bartoszmajsak re-tested e2e on crc after resolving merge conflicts + addressing review. Re-requesting review now when you have time 😃

Copy link
Contributor

@bartoszmajsak bartoszmajsak left a 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 :)

pkg/feature/manifest.go Outdated Show resolved Hide resolved
pkg/feature/manifest.go Show resolved Hide resolved
pkg/feature/manifest.go Show resolved Hide resolved
pkg/feature/manifest_test.go Outdated Show resolved Hide resolved
pkg/feature/manifest_test.go Outdated Show resolved Hide resolved
pkg/feature/manifest_test.go Show resolved Hide resolved
pkg/feature/raw_resources.go Outdated Show resolved Hide resolved
pkg/feature/raw_resources.go Outdated Show resolved Hide resolved
cam-garrison and others added 4 commits February 22, 2024 15:37
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
Co-authored-by: Bartosz Majsak <bartosz.majsak@gmail.com>
@cam-garrison
Copy link
Contributor Author

Hi @zdtsw, removed the refactoring label as I've addressed Bartosz's review. Please take a look whenever you have the chance. Thanks a ton!

@zdtsw
Copy link
Member

zdtsw commented Mar 2, 2024

Hi @zdtsw, removed the refactoring label as I've addressed Bartosz's review. Please take a look whenever you have the chance. Thanks a ton!

sorry, did not get back to you asap.

looks good for me and thanks for the hard (rebase) work

@zdtsw zdtsw added the odh-2.9 label Mar 2, 2024
Copy link
Contributor

@bartoszmajsak bartoszmajsak left a 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.

Copy link

openshift-ci bot commented Mar 4, 2024

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot removed the lgtm label Mar 6, 2024
Copy link

openshift-ci bot commented Mar 6, 2024

New changes are detected. LGTM label has been removed.

@bartoszmajsak bartoszmajsak enabled auto-merge (squash) March 6, 2024 07:18
@zdtsw
Copy link
Member

zdtsw commented Mar 6, 2024

/test opendatahub-operator-e2e

@bartoszmajsak bartoszmajsak merged commit 86c1695 into opendatahub-io:incubation Mar 6, 2024
6 of 7 checks passed
zdtsw pushed a commit to zdtsw-forking/rhods-operator that referenced this pull request Mar 15, 2024
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/...`.
VaishnaviHire pushed a commit to VaishnaviHire/opendatahub-operator that referenced this pull request Mar 19, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants