-
Notifications
You must be signed in to change notification settings - Fork 105
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
base: main
Are you sure you want to change the base?
Changes from all commits
0cadcbc
6d776ef
4edb31e
ae6e148
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? ![]() 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 That paragraph looks contradictory to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. (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.) There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
||
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 | ||
``` | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | | ||
|
@@ -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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Quick question about this sentence:
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 ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's super complicated, but to say it in short,
You can get a full picture from https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/migrate-to-podman-5. Note:
|
||
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 | ||
|
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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:
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).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.