All-in-one Install YAML Manifests for GitOps#115
Open
k-wall wants to merge 10 commits into
Open
Conversation
k-wall
changed the title
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 19, 2026
Add documentation for new rendered install manifest distribution: - New procedures for direct installation from GitHub releases - Documentation for CRDs-first installation workflow - Update release artifacts concepts to describe new formats - Add deprecation notices for combined archive distributions Both operator and admission webhook guides updated. Relates-to: kroxylicious#4016 Relates-to: kroxylicious/design#115 Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 22, 2026
Add support for publishing single-file rendered YAML manifests as
GitHub release assets, following patterns from Strimzi and cert-manager.
New artifacts per component (operator and admission webhook):
- {component}-install-{version}.yaml - Full install (CRDs + resources)
- {component}-crds-{version}.yaml - CRDs only (separate lifecycle)
- {component}-examples-{version}.tar.gz - Examples (separate archive)
Build infrastructure:
- concat_manifests.java - JBang script to concatenate and filter YAMLs
- Maven jbang-maven-plugin executions in package phase
- Assembly descriptors for examples-only archives
Testing:
- RenderedManifestKT integration tests for both components
- Validates manifest completeness and variable substitution
- Tests both single-stage and two-stage installation workflows
All template variables are fully substituted during build.
Manifests include copyright headers and installation instructions.
Relates-to: kroxylicious#4016
Relates-to: kroxylicious/design#115
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 22, 2026
Add documentation for new rendered install manifest distribution: - New procedures for direct installation from GitHub releases - Documentation for CRDs-first installation workflow - Update release artifacts concepts to describe new formats - Add deprecation notices for combined archive distributions Both operator and admission webhook guides updated. Relates-to: kroxylicious#4016 Relates-to: kroxylicious/design#115 Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
changed the title
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 22, 2026
Add support for publishing single-file rendered YAML manifests as
GitHub release assets, following patterns from Strimzi and cert-manager.
New artifacts per component (operator and admission webhook):
- {component}-install-{version}.yaml - Full install (CRDs + resources)
- {component}-crds-{version}.yaml - CRDs only (separate lifecycle)
- {component}-examples-{version}.tar.gz - Examples (separate archive)
Build infrastructure:
- concat_manifests.java - JBang script to concatenate and filter YAMLs
- Maven jbang-maven-plugin executions in package phase
- Assembly descriptors for examples-only archives
Testing:
- RenderedManifestKT integration tests for both components
- Validates manifest completeness and variable substitution
- Tests both single-stage and two-stage installation workflows
All template variables are fully substituted during build.
Manifests include copyright headers and installation instructions.
Relates-to: kroxylicious#4016
Relates-to: kroxylicious/design#115
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 22, 2026
Add documentation for new rendered install manifest distribution: - New procedures for direct installation from GitHub releases - Documentation for CRDs-first installation workflow - Update release artifacts concepts to describe new formats - Add deprecation notices for combined archive distributions Both operator and admission webhook guides updated. Relates-to: kroxylicious#4016 Relates-to: kroxylicious/design#115 Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 22, 2026
Add support for publishing single-file rendered YAML manifests as
GitHub release assets, following patterns from Strimzi and cert-manager.
New artifacts per component (operator and admission webhook):
- {component}-install-{version}.yaml - Full install (CRDs + resources)
- {component}-crds-{version}.yaml - CRDs only (separate lifecycle)
- {component}-examples-{version}.tar.gz - Examples (separate archive)
Build infrastructure:
- concat_manifests.java - JBang script to concatenate and filter YAMLs
- Maven jbang-maven-plugin executions in package phase
- Assembly descriptors for examples-only archives
Testing:
- RenderedManifestKT integration tests for both components
- Validates manifest completeness and variable substitution
- Tests both single-stage and two-stage installation workflows
All template variables are fully substituted during build.
Manifests include copyright headers and installation instructions.
Relates-to: kroxylicious#4016
Relates-to: kroxylicious/design#115
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Keith Wall <kwall@apache.org>
|
This would definitely meet our needs with regards to GitOps deployment, we already deploy cert manager and strimzi operator in the same manner. |
Add proposal for publishing fully-rendered Kubernetes installation manifests as GitHub release assets to enable GitOps workflows. Follows patterns from Strimzi and cert-manager by shipping: - Full install manifests (CRDs + operator resources) - CRDs-only manifests (for separate lifecycle management) - Examples archives (separate from install manifests) Includes 3-release deprecation plan for existing combined archives. Relates-to: kroxylicious/kroxylicious#4016 Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Signed-off-by: Keith Wall <kwall@apache.org>
Remove Flux-specific examples and use simpler Kustomize pattern that works with any GitOps tool. This avoids giving the impression of specific Flux support without automated tests to back it up. Signed-off-by: Keith Wall <kwall@apache.org>
Reflect implementation changes:
- Use Maven classifier-based artifact naming
- Install manifests: artifactId-version-install.yaml
- CRDs manifests: artifactId-version-crds.yaml
- Examples: artifactId-version-examples.{tar.gz,zip}
- Automatic GPG signing via maven-gpg-plugin
- Proper Maven coordinates for deployment
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Keith Wall <kwall@apache.org>
Clarify that deprecated combined archives will be removed at the v1.0.0 milestone (or v0.24.0, whichever comes first), giving users a clear migration target aligned with the 1.0 release. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Remove reference to "final warning" - deprecation will simply be included in release notes for v0.22.0 and v0.23.0. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Rename from "rendered install manifests" to "all-in-one install YAML" for clarity - emphasizes the single-file nature rather than the rendering process. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Lead with the primary issue: archive artifacts are incompatible with GitOps workflows (require download/extract/commit). The inability to use in-tree manifests (unsubstituted variables) is a secondary issue that prevents workarounds. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Correct the current situation - the archives already contain manifests with variables substituted. The problem is the .tar.gz/.zip format itself, not unsubstituted variables. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
Consolidate repetitive content - current situation now just states what exists, motivation focuses on the problem and impact. Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
force-pushed
the
rendered-install-manifests
branch
from
5a524f2 to
0dc9574
Compare
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 23, 2026
Add support for publishing single-file rendered YAML manifests as
GitHub release assets, following patterns from Strimzi and cert-manager.
New artifacts per component (operator and admission webhook):
- {component}-install-{version}.yaml - Full install (CRDs + resources)
- {component}-crds-{version}.yaml - CRDs only (separate lifecycle)
- {component}-examples-{version}.tar.gz - Examples (separate archive)
Build infrastructure:
- concat_manifests.java - JBang script to concatenate and filter YAMLs
- Maven jbang-maven-plugin executions in package phase
- Assembly descriptors for examples-only archives
Testing:
- RenderedManifestKT integration tests for both components
- Validates manifest completeness and variable substitution
- Tests both single-stage and two-stage installation workflows
All template variables are fully substituted during build.
Manifests include copyright headers and installation instructions.
Relates-to: kroxylicious#4016
Relates-to: kroxylicious/design#115
Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/kroxylicious
that referenced
this pull request
Jun 23, 2026
Add documentation for new rendered install manifest distribution: - New procedures for direct installation from GitHub releases - Documentation for CRDs-first installation workflow - Update release artifacts concepts to describe new formats - Add deprecation notices for combined archive distributions Both operator and admission webhook guides updated. Relates-to: kroxylicious#4016 Relates-to: kroxylicious/design#115 Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
SamBarker
reviewed
Jun 26, 2026
| kubectl apply -f https://github.com/kroxylicious/kroxylicious/releases/download/v0.22.0/kroxylicious-operator-dist-0.22.0-install.yaml | ||
| ``` | ||
|
|
||
| **Two-stage installation (CRDs first):** |
Member
There was a problem hiding this comment.
The two-stage installation workflow implies a split-privilege scenario (cluster-admin installs CRDs, namespace-admin installs the operator). But install.yaml is defined as containing CRDs, so the namespace-admin would be re-applying cluster-scoped resources they likely don't have permissions for.
If two-stage is genuinely for split-privilege, I think the artifact split needs to follow the privilege boundary rather than the content type:
install.yaml— everything (for the simple single-admin case, as proposed)cluster-admin.yaml— CRDs, ClusterRoles, ClusterRoleBindings, and any other cluster-scoped resourcesnamespace-admin.yaml— Deployment, Services, namespace-scoped RBAC, etc.
This diverges from cert-manager's crds.yaml naming, but it's clearer about intent and forces us to think about where RBAC resources land — not just "CRDs vs the rest" but "cluster-scoped vs namespace-scoped."
If two-stage isn't intended for split-privilege, what's the use case? Ordering alone doesn't seem to justify it since install.yaml already orders CRDs first.
SamBarker
reviewed
Jun 26, 2026
|
|
||
| **Deprecated:** These combined archives marked as deprecated in release notes. | ||
|
|
||
| **Removed:** Archives removed in v0.24.0 (gives users 2 releases to migrate). |
Member
There was a problem hiding this comment.
nit: The deprecation timeline is stated slightly differently in three places:
- Here: "removed in v0.24.0 (gives users 2 releases to migrate)"
- Line 167: "removed at the v1.0.0 milestone (whichever comes first: v0.24.0 or v1.0.0)"
- Line 225: "Rationale for 3-release timeline"
The thrust is right — deprecate in v0.22.0, remove at v0.24.0 or v1.0.0 (whichever is first). But the three descriptions don't quite agree on whether it's 2 or 3 releases of notice, and this section doesn't mention the v1.0.0 accelerator. Worth a consistency pass.
SamBarker
reviewed
Jun 26, 2026
| 2. Open a PR | ||
| 3. Rename file using PR number: proposals/<PR#>-rendered-install-manifests.md | ||
| 4. Update heading to include PR number | ||
| 5. Push changes |
Member
There was a problem hiding this comment.
nit: Template submission instructions still present — should be removed before merge.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This proposal addresses kroxylicious/kroxylicious#4016 (option 1) by publishing fully-rendered Kubernetes installation manifests as GitHub release assets.
Summary
Enable GitOps workflows by shipping single-file YAML manifests that can be directly referenced via URL, following patterns established by Strimzi and cert-manager.
New Artifacts
All artifacts follow Maven classifier naming conventions (
artifactId-version-classifier.extension):Per component (operator and admission webhook):
{component}-dist-{version}-install.yaml- Full install (CRDs + resources){component}-dist-{version}-crds.yaml- CRDs only (for separate lifecycle){component}-dist-{version}-examples.tar.gz- Examples (separate from install){component}-dist-{version}-examples.zip- Examples (ZIP format)Maven coordinates:
io.kroxylicious:{component}-dist:install:yamlio.kroxylicious:{component}-dist:crds:yamlio.kroxylicious:{component}-dist:examples:{tar.gz,zip}Key Features
kubectl apply -f https://...installationMigration Path
Existing
.tar.gz/.ziparchives (install + examples) will be deprecated and removed in a future release (at v1.0.0 or earlier).Users migrate to separate install manifests + examples archives.
Relates-to: kroxylicious/kroxylicious#4016