COS-2696: common.yaml: enable cliwrap

[jlebon]

As part of the bootable containers effort, we want to put emphasis on a consistent experience when deriving images. A big part of that is being able to type dnf install -y ... in one's Containerfile.

Let's turn on cliwrap for this. This matches the change in FCOS.[1]

[cgwalters]

One thing though is that rhcos already includes python. So I think there's much less motivation for not just shipping dnf.

[jlebon]

One thing though is that rhcos already includes python. So I think there's much less motivation for not just shipping dnf.

Not strongly against, but (1) it's nice to match FCOS, and (2) dnf client-side currently does not work and the UX inconsistency between container flow vs client-side is not great. (Yes, people are not supposed to muck around directly on the host, but they still do it today and will continue to.)

[jmarrero]

/retest-required

[jmarrero]

lgtm

[jmarrero]

/approve

[jmarrero]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jlebon, jmarrero

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jlebon,jmarrero]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dcantrell]

One thing though is that rhcos already includes python. So I think there's much less motivation for not just shipping dnf.

Not strongly against, but (1) it's nice to match FCOS, and (2) dnf client-side currently does not work and the UX inconsistency between container flow vs client-side is not great. (Yes, people are not supposed to muck around directly on the host, but they still do it today and will continue to.)

Can you sync up with re: the UX inconsistency between container flow vs. client-side. This is something I really really want to clean up in dnf, but it's hard to nail down the specifics that people run in to. I think it varies across teams, which is fine, I just need to collect the details.

[jlebon]

Can you sync up with re: the UX inconsistency between container flow vs. client-side. This is something I really really want to clean up in dnf, but it's hard to nail down the specifics that people run in to. I think it varies across teams, which is fine, I just need to collect the details.

Happy to chat some more, but essentially what I mean there is that with the real dnf, dnf install will work in the container flow, but not client-side. (I know with the recent transient root work, it does also work there though we're far from being able to enable that in OCP and it also has different semantics than rpm-ostree install). With cliwrap, dnf install will work both in the container flow and client-side.

I guess one approach there is add some magic in the ostree-rs-ext bits so that we could have real dnf in the container flow, but cliwrapped dnf client-side? That dilutes the message though that the container image is exactly what gets deployed.

So overall, I think this comes back to the dnf image effort. Short-term, I think if dnf implemented cliwrapping itself (i.e. transparently forwarded commands to rpm-ostree on rpm-ostree-managed hosts -- possibly only those without transient root, but I think there are UX questions there to flesh out), then I think we could include it. But ideally, we'd do that in FCOS first, but that's blocked on dnf5 because we want to avoid adding Python there.

[jlebon]

/retest

[jlebon]

coreos/rpm-ostree#4835 should fix the kdump test failure.

[jlebon]

/retest

[openshift-ci-robot]

@jlebon: This pull request references COS-2696 which is a valid jira issue.

In response to this:

As part of the bootable containers effort, we want to put emphasis on a consistent experience when deriving images. A big part of that is being able to type dnf install -y ... in one's Containerfile.

Let's turn on cliwrap for this. This matches the change in FCOS.[1]

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 412d1c6 and 2 for PR HEAD ff686c6 in total

[openshift-ci]

@jlebon: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.