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

yamls: transition to components #614

Merged
merged 3 commits into from
Oct 9, 2023
Merged

yamls: transition to components #614

merged 3 commits into from
Oct 9, 2023

Conversation

sknat
Copy link
Collaborator

@sknat sknat commented Jun 26, 2023

This patch transitions the recursive overalys to using
kubectl kustomize components instead. This makes importing the
same yaml patch (e.g. srv6 ; multinet) in different manifests easier.

We also make sure that all the overlays defined build in the make yaml
directive, even if we do not version the test-* overlays.

@sknat sknat requested review from hedibouattour and onong June 26, 2023 14:00
Copy link
Collaborator

@hedibouattour hedibouattour left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For kind we have both yaml/overlays/kind and yaml/overlays/dev, should we address standardizing things in another PR?

yaml/Makefile Outdated Show resolved Hide resolved
yaml/components/ipsec/README.md Outdated Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those were hardcoded because we don't have prerelease version, we should either add it as a tagged image or make it hardcoded

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For kind we have both yaml/overlays/kind and yaml/overlays/dev, should we address standardizing things in another PR?

I think it's fair to have both :

  • We can have /kind be the generic kind installation (i.e. an external user wanting to install the latest release on a vanilla kind cluster),
  • On the other hand /dev is a really complex overlay which intends to support all the knobs we expose in Calico/VPP. It's true it leverages kind under the hood, but I think usecases are arguably different enough to keep both (or make dev be just an overlay on top of /kind

sknat added 3 commits October 4, 2023 19:05
This patch transitions the recursive overalys to using
kubectl kustomize components instead. This makes importing the
same yaml patch (e.g. srv6 ; multinet) in different manifests easier.

We also make sure that all the overlays defined build in the make yaml
directive, even if we do not version the test-* overlays.

Signed-off-by: Nathan Skrzypczak <[email protected]>
Signed-off-by: Nathan Skrzypczak <[email protected]>
@sknat sknat merged commit d5fb500 into master Oct 9, 2023
3 checks passed
@sknat sknat deleted the yamls-overalays branch October 9, 2023 07:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants