Cirrus: Add packages that provide htpasswd

[cevich]

Mainly needed for buildah testing: the htpasswd command was removed from
the upstream registry container image. Making it available on the
host-side enables configuring details needed by the registry during
it's initial setup.

Signed-off-by: Chris Evich [email protected]

[edsantiago]

Oh good, you're getting the same varlink failures I saw. I'll be curious to see how you resolve those.

[edsantiago]

As best I can interpret, you worked around the varlink problem by just sweeping it under the rug? Doesn't that defer the problem for the next person who does a CI:IMG PR? Would it make sense to at least file an issue? Or have I missed something?

[cevich]

Oh good, you're getting the same varlink failures I saw. I'll be curious to see how you resolve those.

I was half-listening to the chatter about varlink problems during scrum, but I did nothing to resolve other than rebase 😁

Or have I missed something?

Hmm, not sure, or maybe I'm missing something?

TBH I didn't even notice any varlink problems...AFAIR, the main issue I ran into here was a combination of:

• Treating $GOPATH and $GOSRC between testing runtime and VM image build time, differently (value-wise).
• After fixing that, so everything was same-same, I hit a problem building ginkgo/gomega. Brent helped me look at it, and we found (surprise!) it was related to $GOPATH.

I ended up needing to hop onto a VM (with git_ci_vm.sh) to locate the issue in my scripts. Once that was fixed, and (IIRC another rebase), I got an image built successfully and things "just worked" after that.

Does that help? Is there something I need to look into more so we can be sure I didn't rug-sweep on accident?

[edsantiago]

CI failed last night (log) with:

[+0003s] not ok The varlink executable is present: -x 

...which is exactly what I saw in my #6869 (see there for further details on what's failing; it caused me to give up on my PR). Just a few seconds after that failure, you changed the title (removing CI:IMG) and force-pushed a new commit that updated BUILT_IMAGE_SUFFIX but with no change to the failing varlink test. I was just trying to understand why.

If these VMs are only going to be used on the main development branch, it's probably OK to remove the varlink test, and that was going to be my approach. But if these VMs are used on any older branches (which may still need varlink), things may fail in surprising ways. I don't know enough about the varlink situation to understand the ramifications.

[mheon]

Should we just drop that check entirely? We have a completely separate varlink_api test in Cirrus that should, among other things, verify we have a working varlink executable?

[cevich]

but with no change to the failing varlink test. I was just trying to understand why..

Okay sure, yeah I have no doubts as to your motivation, and I think I understand your confusion as well. I'm pretty rigorous about rebasing my PRs when they're close to being "done". That's all I got in terms of "likely explanation" of why it suddenly started working. Too many PRs, too many cycles, too tired old brain 😕

As for your other question/suggestion, and...

Should we just drop that check entirely? We have a completely separate varlink_api test in Cirrus that should, among other things, verify we have a working varlink executable?

I think we should. We have other branches with their own relevant flavor of the CI setup that can be relied upon to test things as required. Since (I'm assuming) varlink isn't needed on the main branch, let's kill it, and have one less thing to possibly flake or do strange things that make Ed slam the door on his own PRs in frustration 😁

(Not to make fun...I've been in your situation Ed, the frustration is real. TBH, there are some parts of CI I don't understand how they work fully. This is where having/trusting a great team is sooo very important.)

[rhatdan]

@cevich what should we do with this PR?

[cevich]

@rhatdan I'm going to rebase once more, and then I think this is good to merge.

[edsantiago]

/lgtm

[rhatdan]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, rhatdan

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 [rhatdan]

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

[edsantiago]

@cevich could you remove the WIP label so we can get this merged? The new images contain crun 0.14, which should (FINALLY) fix the cgroup.freeze flakes that are still affecting us.

[cevich]

Huh? Oh I bet that got stuck because of the rename...