Skip to content

Clarify the latest version of podman 5.2.2 #1599

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions deploy-manage/deploy/cloud-enterprise/configure-host-rhel.md
Original file line number Diff line number Diff line change
Expand Up @@ -100,30 +100,30 @@ Make sure to use a supported combination of Linux distribution and container eng

* For Podman 5

* Install version `5.2.2-13.*` using dnf.
* Install the latest version of Podman `5.2.2` using dnf.

:::{note}
As mentioned in [Migrating to Podman 5](migrate-to-podman-5.md) it is recommended to install Podman `5.2.2-13` since this is the latest supported version.
As mentioned in [Migrating to Podman 5](migrate-to-podman-5.md) it is recommended to install Podman `5.2.2` since this is the latest supported version.
Copy link
Contributor

@eedugon eedugon Jun 17, 2025

Choose a reason for hiding this comment

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

Why recommended? Per our support matrix we only support 5.2.2.

Aren't we saying before this paragraph:

Make sure to use a supported combination of Linux distribution and container engine version as defined in our official Support matrix

In such case I'd say it's mandatory (at the moment) to install 5.2.2, and not recommended. Per the support matrix.

What I'd do is to WARN against 5.2.2 versions that include a memory leak, and saying that we recommend 5.2.2 latest, and certain versions (5.2.2-11 - 5.2.2-13 should be avoided).

Copy link
Contributor

@eedugon eedugon Jun 17, 2025

Choose a reason for hiding this comment

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

If this is the fresh installation document for a new node, there's no need to link the migration to podman 5 document, as it's irrelevant, i would also remove the link and I'd state to stick to support matrix (already in the doc), avoid memory leak versions (if we know them), and suggest 5.2.2 latest as you are already doing.

A link in the migration document towards the normal installation document would make more sense than a link in this doc towards the crazy table of the other doc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

5.2.2-13 is no longer the latest, it was the latest weeks/months ago.
We need to use 5.2.2 so that it can understand the latest automatically - you can see the detailed test log in #1599 (comment).

Again, support matrix is outdated now. I will raise update request today later or tomorrow.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry if I wasn't clear, I was challenging the entire sentence, not your specific change. It doesn't add any value and should be removed from the doc.


If you decide to install a previous Podman 5 version, make sure to replace `5.2.2-13` with the desired version in the commands below.
If you decide to install a previous Podman 5 version, make sure to replace `5.2.2` with the desired version in the commands below.
Copy link
Contributor

@eedugon eedugon Jun 17, 2025

Choose a reason for hiding this comment

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

How can a user DECIDE to install a previous version if it's NOT supported per our support matrix?

image

Didn't we agree some time ago that we wanted to make our docs version agnostic (when possible), and referring to support matrix as the source of truth?

In such case... why we document that the user might want to install a previous version right after saying in an important banner that they must install a compatible OS / Podman version per support matrix?

That paragraph looks contradictory to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@eedugon yes, I will need to raise support matrix update PR in advance.
I only got dev approval from @matt-elastic yesterday so now I can go and file support matrix update.

(That's a different system so it's a bit mixed, but you are right, support matrix is the source of truth, so we must update that too.)

Copy link
Contributor

@eedugon eedugon Jun 17, 2025

Choose a reason for hiding this comment

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

I think you didn't get my point, sorry. I wasn't talking about your specific change, but the entire sentence.,

What I mean is that the entire sentence doesn't add any values because users should NOT decide to install a previous version, as they should refer to the support matrix (which is already stated in the doc).

Actually the entire Note (the 3 paragraphs) should be removed, they don't add value.


The version lock is still required for previous versions, to prevent automatic in-place updates that may be affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473).
:::

```sh
sudo dnf install podman-5.2.2-13.* podman-remote-5.2.2-13.*
sudo dnf install podman-5.2.2 podman-remote-5.2.2
```
* To prevent automatic Podman updates to unsupported versions, configure the Podman version to be locked at version `5.2.2-13.*`.
* To prevent automatic Podman updates to unsupported versions, configure the Podman version to be locked at version `5.2.2`.

```sh
## Install versionlock
sudo dnf install 'dnf-command(versionlock)'

## Lock major version
sudo dnf versionlock add --raw 'podman-5.2.2-13.*'
sudo dnf versionlock add --raw 'podman-remote-5.2.2-13.*'
sudo dnf versionlock add --raw 'podman-5.2.2'
sudo dnf versionlock add --raw 'podman-remote-5.2.2'

## Verify that podman-5.2.2-13.* and podman-remote-5.2.2-13.* appear in the output
## Verify that podman-5.2.2 and podman-remote-5.2.2 appear in the output
sudo dnf versionlock list
```

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ applies_to:

Following are the supported upgrade paths for Podman 5 in {{ece}}.

| **From ↓** ... **To →** | Podman 5.2.2-9 | Podman 5.2.2-11 | Podman 5.2.2-13 | Podman 5.2.3 |
| **From ↓** ... **To →** | Podman 5.2.2-9 | Podman 5.2.2-11 | Podman 5.2.2-latest | Podman 5.2.3 |
|-----------------------------------------|----------------|-----------------|-----------------|--------------|
| **<vanilla Linux installation> (grow)** | ✓ ^*^ | ✓ ^*^ | ✓ | X |
| **Docker (grow-and-shrink)** | ✓ ^*^ | ✓ ^*^ | ✓ | X |
Expand All @@ -18,11 +18,11 @@ Following are the supported upgrade paths for Podman 5 in {{ece}}.



^*^ *Supported but not recommended given that a newer version (Podman `5.2.2-13`) is available.*
^*^ *Supported but not recommended given that a newer version (latest version of Podman `5.2.2`) is available.*

Podman `5.2.2-13` is only supported when conducting a **fresh {{ece}} installation** or performing a **grow-and-shrink update** from Docker or Podman 4.
The latest version of Podman `5.2.2` is only supported when conducting a **fresh {{ece}} installation** or performing a **grow-and-shrink update** from Docker or Podman 4.
Copy link
Contributor

@eedugon eedugon Jun 17, 2025

Choose a reason for hiding this comment

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

That sentence feels incorrect at first sight.

If latest 5.2.2 version of podman is supported in a FRESH installation, why it's not supported in a grow-and-shrink upgrade from Podman 5 when grow-and-shrink means actually installing new nodes and then destroying old ones?

So, if we are doing grow-and-shrink, it should be irrelevant if the original system runs Docker, Podman 4 or Podman 5.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Again, as mentioned in #1599 (comment), it's super complicated, due to the podman memory leak bug as well as the version difference, upgrade method difference, etc.

All behaviors were verified by @matt-elastic from control plane dev team.


For **in-place updates**, it is recommended to use Podman `5.2.2-9`, since upgrades to versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473).
For **in-place updates**, it is recommended to use Podman `5.2.2-9`, since upgrades to versions `5.2.2-11` and latest version of `5.2.2` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473).
Copy link
Contributor

Choose a reason for hiding this comment

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

Quick question about this sentence:

For in-place updates, it is recommended to use Podman 5.2.2-9, since upgrades to versions 5.2.2-11 and latest version of 5.2.2 are affected by a known memory leak issue.

Considering 5.2.2-latest is NOT affected by that known memory leak (please correct me if I'm wrong).... why we don't support an in-place upgrade to 5.2.2-latest and we only support it to 5.2.2-9?

Does the bug affect to 5.2.2-latest when upgrading but not in a new installation? Because it looks very weird in the normal installation doc to tell users to install 5.2.2-latest and then in the migration doc to upgrade to 5.2.2-9 but not 5.2.2-latest.

If the doc is accurate I'd recommend to explain why 5.2.2-latest is the way to go with a new installation (grow-and-shrink update) but not for an in-place upgrade, and why the users should end up in an old (5.2.2-9) release.

Also... I don't understand why we have certain columns with certain patch releases (.9, .11) while other patch releases also exist.

The feeling of the table is that looks over-complicated, and maybe all could be simplified by ensuring we mention to skip / avoid certain releases with the memory leak (-11 and -13?) and then explaining the difference between an in-place upgrade and a grow-and-shrink update.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Considering 5.2.2-latest is NOT affected by that known memory leak (please correct me if I'm wrong).... why we don't support an in-place upgrade to 5.2.2-latest and we only support it to 5.2.2-9?

It's super complicated, but to say it in short,

  • 5.2.2-11 is the buggy version.
  • there's difference between "in-place upgrade" and "grow-and-shrink upgrade / fresh install".

You can get a full picture from https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/migrate-to-podman-5.
=> This doc has 1 place incorrect that the latest version is no longer podman 5.2.2-13, but now is 5.2.2-16. we updated the description to 5.2.2 so it can fetch the latest automatically. again, support matrix needs update too

Note:

  • The logic itself is correct, and
  • the only wrong part is "latest version is no longer 5.2.2-13. We need to update it to 5.2.2-16. And the command to auto-fetch latest version is to use version 5.2.2 specification".
  • all other logic pieces are correct, including the version description about 5.2.2-9 and 5.2.2-11, as well as in place / grow and shrink upgrade, and fresh installation
  • however, support matrix is outdated and needs update.

When performing an in-place update, make sure to configure the Podman version to be locked at version `5.2.2-9.*`, by following the instructions below.

```sh
Expand Down
Loading