8000 kustomization.yaml is not honoured correctly when it comes to subdirectories · Issue #845 · allenporter/flux-local · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

kustomization.yaml is not honoured correctly when it comes to subdirectories #845

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.

Sign up for GitHub

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

Jump to bottom
Open
filipposc5 opened this issue Mar 6, 2025 · 4 comments
Open

kustomization.yaml is not honoured correctly when it comes to subdirectories #845

filipposc5 opened this issue Mar 6, 2025 · 4 comments
Assignees
@allenporter

Comments

@filipposc5
Copy link
Contributor

I have been evaluating using flux-local, thank you for making this tool! One of the issues I came across is that the kustomization.yaml file is not honoured correctly. At first I was testing to see if I can add origin annotations buildMetadata: [ originAnnotations ] inside kustomization.yaml eg:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
buildMetadata: [ originAnnotations ]
resources:
- some-resource-here.yaml 
- more-resources/

which results to an annotation on the objects like

    config.kubernetes.io/origin: |
      path: path/to/file.yaml

and noticed native flux build does create the annotation, but flux-local does not.

I found that pretty strange and whilst iterating I commented out all resources and used resources: [], which again native flux build resulted to 0 resources but flux-local build resulted to quite a few.

Drilling down on the problem, I realised this is because of the structure (updated example kustomization.yaml above to indicate this) - it is correctly not picking some-resource-here.yaml file (expected && good), but it will still traverse inside more-resources/ and generate the other fluxtomizations that exist inside the subdirectory. This behaviour is inconsistent with flux, the expected behaviour is not to recursively add sub-directory resources if they do not exist within the kustomization.yaml.

Version: 7 (behaviour evaluated from ghcr.io/allenporter/flux-local:v7)

I saw a few related issues that may have caused this but did not dig into the code. Let me know if you need any details or clarifications. The originAnnotations is not that severe, but the subdirectory behaviour is a bit more important, thus creating this issue.
@allenporter
Copy link
Owner

Thanks! I definitely am not following the details. It would be really helpful to have an example set of files and expected output vs actual output.

I typically add new clusters in https://github.com/allenporter/flux-local/tree/main/tests/testdata with new edge cases, so we can make a fake repo that reproduces the issue then fix it.

filipposc5 added a commit to filipposc5/flux-local that referenced this issue Mar 10, 2025
@filipposc5
Update for issue allenporter#845
60809af 
Update the repro for 845. Move "apps" under subpath, only include
infrastructure and flux-system.
filipposc5 added a commit to filipposc5/flux-local that referenced this issue Mar 10, 2025
@filipposc5
Test cases for allenporter#845
eb3b0a0 
flux-local vs native
@filipposc5
Copy link
Contributor Author

Hey, I have added full repro here filipposc5#1 and some additional explanation/steps!

I have copied the structure from testdata/cluster:
cp -R ./tests/testdata/cluster/ ./tests/testdata/cluster10

I created two testcases, one with flux-local and one with flux build native to show 'actual' and 'expected'. The apps have been moved to a subdirectory that should not be included as kustomization.yaml does not include it (I have simplified the file just to demonstrate the issue). We see that apps are included even though they are not supposed to be compared to a native flux build.

(Also TIL: syrupy, what is this magic :D )

@allenporter allenporter self-assigned this Mar 11, 2025
@allenporter
Copy link
Owner

Awesome, thank you! I will check this out, it definitely makes this a lot easier to get started on addressing.

@allenporter
Copy link
Owner

Currently these attributes are intentionally stripped here to remove noise:

flux-local/flux_local/visitor.py

Line 237 in 1c92618

# Remove common noisy labels

To address this I believe what needs to happen is:
(1) the stripping needs to move closer to the flux build call
(2) the flux build call needs to take the buildMetadata as input to decide to not strip those attributes, essentially making it a default true behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@allenporter allenporter

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@filipposc5 @allenporter
0