Hello Foreman community!
We’re working on adding a new feature to the Foreman. In the image mode hosts you will be now able to distinguish between transient package and persistent packages . The goal is to help you easily track packages installed on image mode hosts that have drifted from the original container image. This gives you a clear understanding of what’s been added and helps you incorporate those changes into future images. What’s more we will be adding a way to generate a ContainerFile command for selected packages.
Proposed design
(Note: dummy data displayed in the screenshots)
Persistence column
In the Host Details > Content > Packages section, we’re adding a new column to the UI. This will help you track transient packages.
We’re adding the ability to act on this information directly. You’ll be able to select transient packages and from the toolbar’s kebab generate a RUN command that you can copy and paste into your Containerfile. This will help you incorporate these packages into your next container image.
Do you need to review the command before copying it?
Does the action name (Generate ContainerFile command) accurately describe the action’s outcome? (Would you expect different behaviour?)
Please review and let us know what you think in the comments below!
Your feedback is crucial for us. We appreciate your time and contribution to making Foreman even better.
I think the snippet I see on the screenshot above is enough for me to decide if this is something I want to add to my Containerfile or not.
I’d call it Generate Cotnainerfile snippet. It’s not full Containerfile. Also note the capitalization, I never saw ContainerFile before, I think it’s just Containerfile.
One question - is the Persistence column added only if the host is detected as image mode?
Otherwise I like it and find it quite straightforward, nice work.
The persistence column will be displayed just for image mode hosts. There is no need to show it for package mode hosts.
Capitalisation is off, thanks.
@maximilian Layer: I am not sure what you mean by this - is it an action name? Generate Containerfile layer? Icons: Using the same icon for two different functions, especially if they have different tooltips, could be confusing for users. This could lead to misinterpretation and a poor user experience since it would be displayed on the same (the host name would have the icon with the tooltip image mode, but the package would have the same icon with the tooltip transient).
@jeremylenz it may be enough to support just a query filtering
Thanks for explaining @MariSvirik I didn’t realize it’s only about image mode hosts.
RE layers: I mean that if you append a “RUN” statement to a Containerfile and build a container image based on it, then you’ll basically add a layer to it. In general, each statement in a Containerfile results in a layer in the built container image.
I don’t know if using “layer” in the title makes it any better though. To me, a command is something that I run. If users click copy, we expect them to add this /append their existing Containerfile.
I’d like to add some technical details for how the transient packages will be tracked in the backend. We’re currently requesting that libdnf will provide a new API for fetching which packages are transient. Then, the API can be used in subscription-manager to add a ‘persistence’ option to the package profile.
In subscription-manager, you’ll find the following:
# Snippet from https://github.com/candlepin/subscription-manager/blob/3eb3ca50939ebf7b177bdaa1d10a74095ebbe33e/src/rhsm/profile.py#L369-L385
...
log.debug("Loading current RPM profile.")
ts = rpm.TransactionSet()
ts.setVSFlags(-1)
installed = ts.dbMatch()
self.packages = self._accumulate_profile(installed)
...
One way or another, we’ll be able to load the package persistence here for inclusion in the package profile like so:
