Skip to content

Fix: tenant-root domain always overrided to example.org - #10

Merged
Andrei Kvapil (kvaps) merged 1 commit into
mainfrom
fix-root-domain
Feb 9, 2024
Merged

Fix: tenant-root domain always overrided to example.org#10
Andrei Kvapil (kvaps) merged 1 commit into
mainfrom
fix-root-domain

Conversation

@kvaps

@kvaps Andrei Kvapil (kvaps) commented Feb 9, 2024

Copy link
Copy Markdown
Member

.Capabilities.APIVersions.Has "helm.toolkit.fluxcd.io/v2beta1 does not work for Helm Template, so we must explicity pass apiversions to helm template command

see: helm/helm#10760

Comment thread packages/core/platform/Makefile Outdated

show:
helm template -n $(NAMESPACE) $(NAME) . --dry-run=server
helm template -n $(NAMESPACE) $(NAME) . --dry-run=server $$(kubectl api-versions | awk '{print "-a " $$1}')

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I don't like interpolations with

$(bash_command)

or

`(bash_command)`

as they can lead to very difficult to debug errors. The better approach is to use xargs:

kubectl api-versions | awk '{print "-a " $$1}' | xargs -r -I{} helm template -n $(NAMESPACE) $(NAME) . --dry-run=server {}

in case if awk will return empty string, xargs won't run at all.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

like bonus - you don't need to use awkward syntax like double dollar

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

yeah, but you still need it for awk :)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I still have concerns about using xargs it might work diferent on various systems, awk is always the same.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Not 100% accurate, you have gawk and mawk :)

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
@kvaps

Copy link
Copy Markdown
Member Author

George Gaál (@gecube) I rebased the PR to use pure Makefile, without any xargs and awk. please review

@kvaps
Andrei Kvapil (kvaps) merged commit 70bb724 into main Feb 9, 2024
@themoriarti
Marian Koreniuk (themoriarti) deleted the fix-root-domain branch August 5, 2024 20:52
Matthieu ROBIN (matthieu-robin) pushed a commit to matthieu-robin/cozystack that referenced this pull request May 17, 2026
Following kvaps' review, move the ZK→KRaft migration logic out of the
chart templates and into a pre-upgrade Job gated by a
<release>-kafka-deployed-version ConfigMap (seaweedfs/etcd pattern).

The chart now ships pure KRaft on day one:
- Kafka CR always renders with strimzi.io/kraft=enabled and no
  spec.zookeeper block.
- All lookup-based state detection is removed from kafka.yaml,
  kafkanodepools.yaml, metrics-configmap.yaml, workloadmonitor.yaml and
  dashboard-resourcemap.yaml.
- The zookeeper: block is dropped from values.yaml, values.schema.json,
  types.go and the kafka-rd openAPISchema.

Migration of existing ZK clusters is handled by a new
templates/migration-hook.yaml that renders only when the version
ConfigMap is missing or below "1". The Job creates broker + controller
KafkaNodePools (with Helm ownership labels so the subsequent chart
apply can adopt them), annotates the Kafka CR with
strimzi.io/node-pools=enabled and strimzi.io/kraft=migration, polls
status.kafkaMetadataState until KRaftPostMigration or later, flips the
annotation to enabled and waits for KRaft.

Deviation from kvaps' proposal: separate broker+controller pools
instead of a combined pool. Strimzi 0.45 does not support migration
into a combined pool, so a homogeneous separate-pool layout works for
both fresh installs and migrations without conditional logic.

Other review fixes:
- _versions.tpl: sortAlpha on the allowed-versions error message (cozystack#10).
- e2e: rebased on main (event-driven kubectl waits), drops zookeeper
  readiness checks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Matthieu ROBIN (matthieu-robin) pushed a commit to matthieu-robin/cozystack that referenced this pull request May 17, 2026
Following kvaps' review, move the ZK→KRaft migration logic out of the
chart templates and into a pre-upgrade Job gated by a
<release>-kafka-deployed-version ConfigMap (seaweedfs/etcd pattern).

The chart now ships pure KRaft on day one:
- Kafka CR always renders with strimzi.io/kraft=enabled and no
  spec.zookeeper block.
- All lookup-based state detection is removed from kafka.yaml,
  kafkanodepools.yaml, metrics-configmap.yaml, workloadmonitor.yaml and
  dashboard-resourcemap.yaml.
- The zookeeper: block is dropped from values.yaml, values.schema.json,
  types.go and the kafka-rd openAPISchema.

Migration of existing ZK clusters is handled by a new
templates/migration-hook.yaml that renders only when the version
ConfigMap is missing or below "1". The Job creates broker + controller
KafkaNodePools (with Helm ownership labels so the subsequent chart
apply can adopt them), annotates the Kafka CR with
strimzi.io/node-pools=enabled and strimzi.io/kraft=migration, polls
status.kafkaMetadataState until KRaftPostMigration or later, flips the
annotation to enabled and waits for KRaft.

Deviation from kvaps' proposal: separate broker+controller pools
instead of a combined pool. Strimzi 0.45 does not support migration
into a combined pool, so a homogeneous separate-pool layout works for
both fresh installs and migrations without conditional logic.

Other review fixes:
- _versions.tpl: sortAlpha on the allowed-versions error message (cozystack#10).
- e2e: rebased on main (event-driven kubectl waits), drops zookeeper
  readiness checks.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Matthieu <matthieu@hidora.com>
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.

4 participants