Docker provider e2e test

[stevenhorsman]

This is based on Wainer's PR #1965, with some work done to make it fit into the new e2e world

[wainersm]

Thanks @stevenhorsman !

I ran on my fork but it failed to install caa: https://github.com/wainersm/cc-cloud-api-adaptor/actions/runs/12180636082/job/33975999946

I will add a step to gather logs at the end of the job on fail, as we do for libvirt.

[wainersm]

@stevenhorsman pushed two new commits to enable debug on docker workflow.

On https://github.com/wainersm/cc-cloud-api-adaptor/actions/runs/12185682757/job/33993001651, it fail to start caa:

  Usage: cloud-api-adaptor <provider-name> [options] | help | version
  
  Supported cloud providers are:
  	gcp
  	azure
  	aws
  	ibmcloud
  	vsphere

The caa image being used has no support for docker... is the support built in by default?

[stevenhorsman]

So we need to use the dev image to get libvirt support due to libvirt using cgo bindings.

[stevenhorsman]

I think there is also an issue with CAA_IMAGE envs (and properties) just being ignored, so I might switch docker to use the same mechanism as libvirt and do the kustomize rather than install directory.

[stevenhorsman]

@wainersm I've made and pushed the change that should fix the CAA issue and testing it now. I think it can be fixup'd into a previous commit, but as it might be controversial I wanted to give you the chance to see it first

[wainersm]

Hi @stevenhorsman !

@wainersm I've made and pushed the change that should fix the CAA issue and testing it now. I think it can be fixup'd into a previous commit, but as it might be controversial I wanted to give you the chance to see it first

I accepted the pre_install stuff makes no sense anymore. Yep, let's remove it completely when we finish the removal of packer workflows. Ah, I think we should leave your last commit as is, the commit message has a nice explanation for the history of this git repository.

Did the test finish? Worked out?

[stevenhorsman]

Did the test finish? Worked out?

The test failed: https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/12196066119/job/34023415633 We only seem to get the last ~10 lines of the CAA log which isn't super helpful in this case. I think it might have to be a manual debug, though I tried that a few weeks ago when I first wrote some of this code and didn't get very far. I'm not sure if we still get this problem: https://github.com/confidential-containers/cloud-api-adaptor/tree/main/src/cloud-api-adaptor/docker#troubleshooting that used to always happy on the docker provider?

[wainersm]

Did the test finish? Worked out?

The test failed: https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/12196066119/job/34023415633 We only seem to get the last ~10 lines of the CAA log which isn't super helpful in this case. I think it might have to be a manual debug, though I tried that a few weeks ago when I first wrote some of this code and didn't get very far. I'm not sure if we still get this problem: https://github.com/confidential-containers/cloud-api-adaptor/tree/main/src/cloud-api-adaptor/docker#troubleshooting that used to always happy on the docker provider?

Yeah, I will reserve some time to debug locally. In any case I sent an fixup to print all caa log messages.

For the records, I never made the docker provider to work locally (nor on my tentative to introduce the CI workflow) :(

[stevenhorsman]

For the records, I never made the docker provider to work locally (nor on my tentative to introduce the CI workflow) :(

Yeah, I haven't had it working for a long time. I think Pradipta might have though.