feat(kustomize): use LabelTransformer instead of deprecated commonLabels #1017
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Great, when you manage to run it and it finds no changes, you can expect automatic lgtm from me. Meanwhile, I tried to run kustomize on the project manifests
and
not sure what I'm doing wrong, but will look tomorrow |
|
Interesting observation @jiridanek ... i will look into it more.. but fwiw - I do not use standalone
for now, to play around.. maybe avoid the UPDATE
|
andyatmiami
force-pushed
the
fix/kustomize-labeltransformer
branch
from
aacfa6c to
272f4ce
Compare
andyatmiami
force-pushed
the
fix/kustomize-labeltransformer
branch
from
272f4ce to
65ed7d8
Compare
This is a "piece" of a more comprehensive/interesting PR: - opendatahub-io#1015 Unfortunately, that PR has grown wildly unwieldy in its size - and immediate feedback received was to try to break it into smaller pieces - so consider this one piece! The ulitmate goal here on this targetted PR is two-fold: - standardization irrespective of image build "flavour" our kustomize labelling - get rid of following warning: ``` $ kubectl kustomize jupyter/minimal/ubi9-python-3.11/kustomize/base ... ``` No actual changes are introduced in this PR - simply leveraging the `LabelTransformer` to accomplish what `commonLabels` was previously doing. Related-to: https://issues.redhat.com/browse/RHOAIENG-23291
andyatmiami
force-pushed
the
fix/kustomize-labeltransformer
branch
from
65ed7d8 to
f4a1c0a
Compare
|
Output of running my |
|
@andyatmiami I have a feeling we are duplicating our work here? #996 Also regarding the kustomize output comparison, I have something in my wip branch too for the followup of my raised 996 PR. |
|
I decided not to say anything before because Andy is quite good at pushing change forward. Better than you and me, if I say so. |
|
And this is nice isolated and focused change pr that can just slip in nicely, so why not just merge it and skip all the polite social chatter about being so sorry to have missed your or, and so on :p |
I knew I needed older kustomize, that's why I downloaded 5.5 when I have 5.6 on my system. Just completely did not realize I need very much older kustomize. |
|
/lgtm |
|
/override ci/prow/runtimes-ubi9-e2e-tests |
|
@jiridanek: Overrode contexts on behalf of jiridanek: ci/prow/rocm-runtime-tf-ubi9-python-3-11-pr-image-mirror, ci/prow/rocm-runtimes-ubi9-e2e-tests, ci/prow/runtimes-ubi9-e2e-tests In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hey folks, I just reviewed this PR as well as Jan's. I tend to prefer the approach to labels used in this PR. Jan, the other changes in your PR regarding placeholders still look relevant and seem like another piece of the ongoing transition toward a better kustomization declaration. |
My personal preference would be to go without the extra
Definitely not as part of this PR but as a separate change.
This is due to the: inclusion - once we get rid of the variables deprecation, kustomize 5.6 will work (as it works in the #996 PR already). |
|
I'm undecided regarding the extra files. I guess i slightly prefer to have extra files. /lgtm |
|
Merging the other pr would be easier procedurally, no rebase needed... that's true |
|
Closing this PR in favor of: |
…flux/component-updates/component-update-odh-workbench-jupyter-datascience-cpu-py311-ubi9-n-v2-23 chore(deps): update odh-workbench-jupyter-datascience-cpu-py311-ubi9-n-v2-23 to 53a5394
Description
This is a "piece" of a more comprehensive/interesting PR:
Unfortunately, that PR has grown wildly unwieldy in its size - and immediate feedback received was to try to break it into smaller pieces - so consider this one piece!
The ulitmate goal here on this targetted PR is two-fold:
No actual changes are introduced in this PR - simply leveraging the
LabelTransformerto accomplish whatcommonLabelswas previously doing.Related-to: https://issues.redhat.com/browse/RHOAIENG-23291
How Has This Been Tested?
The following command (replacing the directory as appropriate) can be used to have
kustomizeprocess our manifests:kubectl kustomize jupyter/minimal/ubi9-python-3.11/kustomize/baseFor verification purposes - one can then simply compare the output of
kustomizeon this branch with that ofmain.Here is a simple script that can do the verifications FOR YOU
labeltransformer-verify.sh.txt
.txtextension and make sure file executablekustomize(5.0.3) is downloaded and used by this script as later versions have a more strict parserMerge criteria: