Add possibility to choose podman instead of docker for building golang operator, bundle and catalog image

[stanislavulrych]

Feature Request

Description

Currently, the docker is used as a build tool for operator images. Other container tools could be used to build the images. Since podman cli has syntax compatible with docker, it could be easily used by just allowing a change of the tool.

• In order to change the container tool for image build, it has to be changed on mulltiple locations in the Makefile.
• The suggested feature would introduce the Makefile variable CONTAINER_TOOL to allow setting of the container tool for build.
• The default value of the CONTAINER_TOOL would be docker, hence this feature is backward compatible and does not impact the current usage.

/language go

[mhrivnak]

+1. I've had success both doing a find/replace in the Makefile, and installing the podman-docker package in fedora, which just creates a shell alias. Either way, the workflows in the Makefile seem completely compatible.

[everettraven]

#6090 was created to address this. In the process of creating the PR it was determined that changes upstream in Kubebuilder would need to be made to add conditional logic to run a different set of commands for building multi-arch images when using podman instead of docker.

@stanislavulrych mentioned trying to take this on in a comment on the PR: #6090 (comment)

[stanislavulrych]

@everettraven I am sorry for the delay, I tried to address the issue in kubebuilder, but I am not familiar with the code much, so it will take me more time. I am still interested in the feature.

[everettraven]

@stanislavulrych No worries! I was asked during our community meeting to add an update comment so that's all that comment is supposed to be

[varshaprasad96]

This seems to be blocked by Kubebuilder. Removing this from milestone and adding to the backlog. If anyone is interested in picking this up, please feel free to assign yourself.

[everettraven]

/unassign

[redhatrises]

@everettraven @varshaprasad96 feel free to assign me to it. I will work on getting it into kubebuilder if no one else has.

[redhatrises]

Upstream PR: kubernetes-sigs/kubebuilder#3371

[KevinMGranger]

It's merged upstream, woo! So what's the next step now?

[everettraven]

The next step would be to update our Kubebuilder dependency to a version that contains the commit with this change. Then we should automatically inherit that behavior 🎉

[redhatrises]

Can the existing implementation be used in init.go and just updated? Or does there need to be a v4 version of the plugin here in this SDK?

[everettraven]

So it looks like we do have an implementation for the go/v4 plugin in place here but is still in "alpha":

operator-sdk/internal/cmd/operator-sdk/cli/cli.go

Lines 92 to 99 in 6a6edfd

	gov4AlphaBundle, _ := plugin.NewBundle(golang.DefaultNameQualifier, plugin.Version{Number: 4, Stage: stage.Alpha},
	kustomizev2Alpha.Plugin{},
	// # TODO(rashmigottipati): make v4 stable with the next release of KB
	// as `go/v3` is getting deprecated by KB hence Operator SDK would also be migrating to v4 soon.
	golangv4.Plugin{},
	manifestsv2.Plugin{},
	scorecardv2.Plugin{},
	)

When we bump our kubebuilder dependency we need to:

• Update the go/v4 plugin to be stable (unmark it as alpha)
• Remove the go/v2 plugin (earlier in the file that contains the code I shared above)
• Mark the go/v3 plugin as deprecated (earlier in the file that contains the code I shared above)
• Make go/v4 the default plugin used (if not already)

IIUC the changes made in Kubebuilder, once this is done we should inherit those changes

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.