Add Katello 4.16 release notes #3693
Conversation
github-actions
bot
added
Needs tech review
|
The PR preview for 08c74b8 is available at theforeman-foreman-documentation-preview-pr-3693.surge.sh The following output files are affected by this PR: |
| === Image-mode host support | ||
|
|
||
| Katello has added a new type of host: image-mode hosts. | ||
| Image-mode hosts are standard hosts configured to run a bootc bootable container image at startup. |
There was a problem hiding this comment.
Standard host makes me think of package mode hosts. Maybe just say something like "Image mode hosts are ostree-based and provisioned with bootable container images."
|
|
||
| Katello has added a new type of host: image-mode hosts. | ||
| Image-mode hosts are standard hosts configured to run a bootc bootable container image at startup. | ||
| Katello 4.16 allows users to assign bootable container images to an image-mode host to easily deploy identical system configurations, from basic to complex. |
There was a problem hiding this comment.
This makes it sound like assigning images to the host is the core workflow, maybe something like:
"... enables users to register image mode hosts, view bootc-related statistics, and remotely execute bootc commands."
| Existing hosts are now considered 'package-mode hosts' and will exist alongside the new host type. | ||
| Both host types can be set up and configured using existing host management processes. | ||
|
|
||
| Bootable container images (bootc images) can be managed similarly to existing Foreman repositories. |
There was a problem hiding this comment.
Not sure we need a line about bootable container images since they are just container (docker) repositories.
I suppose you could add something like "Consider syncing bootable container images and serving them to image mode hosts in your infrastructure."
There was a problem hiding this comment.
Or emphasize they're just OCI compatible images by saying something like "Bootable container images are OCI compliant images and can be managed using existing container repository management tooling in Katello".
| === Flatpak content support | ||
|
|
||
| Katello now supports Flatpak content. | ||
| Flatpak content can be manually added as a local repository or can be imported from external sources as a Flatpak remote repository. |
There was a problem hiding this comment.
Perhaps worth mentioning that all of these new flatpak helpers are only available via hammer (and API) for now.
There was a problem hiding this comment.
Also maybe worth mentioning that only the OCI flatpaks are supported (OSTree are not).
| === Flatpak content support | ||
|
|
||
| Katello now supports Flatpak content. | ||
| Flatpak content can be manually added as a local repository or can be imported from external sources as a Flatpak remote repository. |
There was a problem hiding this comment.
Also maybe worth mentioning that only the OCI flatpaks are supported (OSTree are not).
|
|
||
| Katello now supports Flatpak content. | ||
| Flatpak content can be manually added as a local repository or can be imported from external sources as a Flatpak remote repository. | ||
| After import, Flatpak remote repositories can be mirrored to local Katello repositories via remote repository mirroring. |
There was a problem hiding this comment.
| After import, Flatpak remote repositories can be mirrored to local Katello repositories via remote repository mirroring. | |
| After scan, Flatpak remote repositories can be mirrored to local Katello repositories via remote repository mirroring. |
We call it "scan", but import is probably usable too as an abstraction what it does.
| Katello now supports Flatpak content. | ||
| Flatpak content can be manually added as a local repository or can be imported from external sources as a Flatpak remote repository. | ||
| After import, Flatpak remote repositories can be mirrored to local Katello repositories via remote repository mirroring. | ||
| Flatpak repositories (local or remote) can be easily installed and synced on remote hosts via any of Katello's existing repository management techniques. |
There was a problem hiding this comment.
| Flatpak repositories (local or remote) can be easily installed and synced on remote hosts via any of Katello's existing repository management techniques. | |
| Flatpak repositories can be easily synced and installed on remote hosts via any of Katello's existing repository management techniques. |
I would omit the (local or remote) here, it's a bit confusing. During remote repository mirroring a local repository is created and only that can be synced and consumed at a host, in this order.
There was a problem hiding this comment.
In our regular contributors list we don't include email addresses
| === postgresql-evr extension no longer required | ||
|
|
||
| Installation of the Katello database on remote systems where root access is not available is now possible. | ||
| Only a basic PostgreSQL installation is required. | ||
| With this feature, you can now install on systems like Amazon RDS or Azure Database for PostgreSQL. | ||
|
|
||
|
|
||
| === Rails 7.0 support |
There was a problem hiding this comment.
Isn't this a Foreman feature? I wouldn't list this since it shouldn't be a user visible change.
|
|
||
| === Organization custom labels | ||
|
|
||
| Organizations now support the ability to use user-submitted labels during creation. |
There was a problem hiding this comment.
This doesn't really help me understand why I would like this feature. How does an organization use labels?
What changes are you introducing?
Add Katello 4.16 release notes
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Standard release procedure.
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
[see comment below]
Checklists
Please cherry-pick my commits into: