Add release notes for 3.4 release

[pkoutsovasilis]

This PR adds the release notes for 3.4 release

[prodsecmachine]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[pkoutsovasilis]

Both #9287 and #9291 are merged and backported

For now I have included the bump of default memory limits for Kibana to 2Gi in the breaking changes section

[github-actions]

🔍 Preview links for changed docs

• docs/reference/api-reference/3_4_0.md
• docs/reference/third-party-dependencies/3_4_0.md
• docs/release-notes/breaking-changes.md
• docs/release-notes/deprecations.md
• docs/release-notes/index.md
• docs/release-notes/known-issues.md

[github-actions]

Vale Linting Results

Summary: 2 warnings found

⚠️ Warnings (2)

File	Line	Rule	Message
docs/reference/third-party-dependencies/3_4_0.md	17	Elastic.BritishSpellings	Use American English spelling 'license' instead of British English 'Licence'.
docs/reference/third-party-dependencies/3_4_0.md	73	Elastic.BritishSpellings	Use American English spelling 'license' instead of British English 'Licence'.

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[barkbay]

Error: 'deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-scheduling.md' has no anchor named: '#k8s-zone-awareness'.
    ┌─[/github/workspace/docs/release-notes/index.md]
    │
 26 │ ECK simplifies the configuration of zone awareness for {{es}} clusters, reducing the amount of boilerplate configuration needed to set up topology-aware allocation. For more details, refer to the [zone awareness documentation](docs-content://deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-scheduling.md#k8s-zone-awareness).

I guess it is because the change is not in main yet: https://github.com/elastic/docs-content/pull/5838/changes#diff-f358dbb582798451c241f819cfdbbd0afbf58f0d4f81da5895838647e079c16f Should be ok once the docs pr is merged I guess.

[pkoutsovasilis]

I guess it is because the change is not in main yet: https://github.com/elastic/docs-content/pull/5838/changes#diff-f358dbb582798451c241f819cfdbbd0afbf58f0d4f81da5895838647e079c16f Should be ok once the docs pr is merged I guess.

My guess is the same as yours 🙂

[barkbay]

A few observations on the Features and enhancements list:

• Validate user-supplied CA for the transport layer of {{es}} [#8953] is labeled >bug and the PR title starts with fix:. It should probably move to the Fixes section.

• Align DaemonSet UpdateReconciled with Deployment reconciler [#9256] also has a fix: PR title and explicitly fixes #9246, aligning DaemonSet with a bug that had already been fixed in Deployment and StatefulSet. Feels like a Fixes entry?

• Set TransformStripManagedFields on informer caches [#9321] feels too technical as written. The actual user benefit is a noticeable reduction in operator memory footprint, per the PR description. Something like "Reduce operator memory footprint by stripping managed fields from informer caches" would communicate that better.

• Sign ECK container images (v2) [#9078] feels like it could deserve a Release Highlight. Image signing is a meaningful security feature that users can act on (verifying signatures), and it is a first for ECK.

[pebrc]

A few comments inline. I also wanted to point out a rolling restart was not considered a breaking change in the past. I know the category also lists "operational disruptions" as "breaking" so I am OK with listing them here, even though if ECK works correctly there should not be any service disruption (but in some cases with larger nodes a drop in throughput etc).

[pebrc]

The framing here is not correct imo. Configuration changes that require a restart are handled by ECK already. This is more of a troubleshooting mechanism

[pkoutsovasilis]

troubleshooting mechanism it is, changed in fe75460

[pebrc]

"FIPS-compliant" is a loaded term — ECK doesn't guarantee FIPS compliance, it satisfies the Elasticsearch requirement of a password-protected keystore when running in FIPS mode. Suggest rewording to avoid the compliance claim:

Suggested change

	#### Operator-managed FIPS keystore password support for {{es}}
	ECK now automatically manages FIPS-compliant keystore passwords for {{es}}. When FIPS mode is enabled in the {{es}} configuration (`xpack.security.fips_mode.enabled: true`), the operator generates, stores, and configures a password-protected keystore — eliminating the need for manual `podTemplate` overrides. This feature activates for {{es}} 9.4.0+ and respects any existing user-provided keystore password configuration. For more details, refer to the [{{es}} FIPS keystore password documentation](docs-content://deploy-manage/deploy/cloud-on-k8s/deploy-fips-compatible-version-of-eck.md#k8s-fips-keystore-password).
	#### Operator-managed FIPS keystore password support for {{es}}
	ECK now automatically manages a password-protected keystore for {{es}} when FIPS mode is enabled. When `xpack.security.fips_mode.enabled` is set to `true` in the {{es}} configuration, the operator generates, stores, and configures a password-protected keystore — eliminating the need for manual `podTemplate` overrides. This feature activates for {{es}} 9.4.0+ and respects any existing user-provided keystore password configuration. For more details, refer to the [{{es}} FIPS keystore password documentation](docs-content://deploy-manage/deploy/cloud-on-k8s/deploy-fips-compatible-version-of-eck.md#k8s-fips-keystore-password).

[pkoutsovasilis]

valid point, changed in fe75460

[pebrc]

The maintenance window recommendation here (and in the ES client cert entry on line 43) seems at odds with what ECK is designed to do — rolling restarts are supposed to be disruption-free by respecting PDBs, managing shard reallocation, and checking cluster health before proceeding. Recommending a maintenance window undermines confidence in that mechanism.

Also, the guidance is inconsistent across the four rolling restart entries: this one and the ES client cert entry recommend a maintenance window, while the Kibana init container and Kibana memory limit entries don't.

I'd suggest dropping the maintenance window language from all rolling restart entries and using consistent wording like "No action required. Be aware that [affected pods] will restart during the operator upgrade." — similar to what the Kibana init container entry already says.

[pkoutsovasilis]

dropped in fe75460

[pebrc]

Consider consolidating the four rolling restart entries into one per affected workload. A customer doesn't care whether ES restarts because of the client cert feature or the seccompProfile change — they care that ES pods will restart during the upgrade. The current structure reads like an internal changelog rather than user-facing guidance.

Suggested structure:

1. {{es}} pods will restart during the operator upgrade — one entry covering all ES pod spec changes (seccompProfile, client cert scripts). No action required beyond awareness.
2. {{product.kibana}} pods will restart during the operator upgrade — one entry covering init container security context and memory limit changes. This one should still call out the OOM risk for users with explicit memory limits below 2Gi, since that has a distinct action item.
3. Default PVC handling change — keep as-is, it has its own distinct action.

This reduces five entries to three, and each maps to something the user can actually act on rather than listing internal implementation reasons for the same observable outcome.

[pkoutsovasilis]

consolidated in fe75460