Add support for OpenStack

[cw-kojima1003]

Summary:
This pull request allows cloud-api-adaptor(CAA) to support OpenStack-based clouds.

Background:
There is currently no provider in CAA that supports clouds built with standard OpenStack.
By implementing an OpenStack provider, we can offer secure pod execution environments in a wider range of fields.

As stated in the link below, we are focusing on implementations related to ARM CCA.
This PR provides an architecture-independent implementation.
Moving forward, we aim to execute PeerPods on OpenStack clouds that support ARM CCA.

Links:
This PR is for the purpose and related work described in the following Issue.
#2387

Task:
Adding an built-in Provider for OpenStack, referring to the following documentation.

https://github.com/confidential-containers/cloud-api-adaptor/blob/main/src/cloud-api-adaptor/docs/addnewprovider.md

• Add and initialize the OpenStack provider manager
• Add a definition for the configuration struct
• Add cloud interfaces
• Add provider interfaces
• Add additional files to modularize the code
• Add relevant unit tests
• Update entrypoint.sh and Makefile

Implemented:

• Launch Peer Pod with standard VM
• Unit tests
• Manual connectivity verification

Future implementation:

• [] Validate user-data reception on the Pod VM image
  The user-data related features are currently foundational, with validation and testing for operational integrity still pending.
• [] Create documentation for CAA deployment and Pod VM creation steps
• [] Implement end-to-end (E2E) tests (CI) for the new provider
• [] Enable CVM (Confidential Virtual Machine) launch for CCA support
• [] Other features: pause-image, VXLAN, TLS, etc

[mkulke]

I have some reservations about adding a provider without e2e tests, we cannot really make any statements about whether a provider is working or not without those.

What kind of PodVM image can be used with the provider?

[cw-kojima1003]

@mkule, thank you for your comment.

The details of the Pod VM image used are as follows:

Image source: https://quay.io/repository/confidential-containers/podvm-generic-ubuntu-amd64

For obtaining the image, we used the download-image.sh script provided by CAA.
Here is the command we used to obtain the image:

$ ./src/cloud-api-adaptor/podvm/hack/download-image.sh quay.io/confidential-containers/podvm-generic-ubuntu-amd64:v0.17.0 . -o podvm.qcow2

The obtained image was placed within the locally constructed OpenStack cluster.

I have some reservations about adding a provider without e2e tests, we cannot really make any statements about whether a provider is working or not without those.

The e2e tests are currently underway and will be committed at a later date.
We initially planned to submit the e2e tests as a separate pull request, but we can also add them to this PR.
Could you please share your opinions on this?

Finally, I have conducted PeerPod functionality tests in my local environment.
BusyBox was used to initiate the Pod.
Below, you'll find the YAML file we referenced:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: busybox
  name: busybox
spec:
  containers:
  - image: quay.io/prometheus/busybox
    name: busybox
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
  runtimeClassName: kata-remote

[cw-kojima1003]

golangci-lint reported several unhandled error returns in the OpenStack support code.
This change updates the code to receive and properly handle the returned errors.
preventing the same errcheck warnings from being repeatedly reported in CI.

[bpradipt]

@cw-kojima1003 now that 0.18 release is out, can you please rebase your PR. It'll make it easier to review

[cw-kojima1003]

@bpradipt
Sorry for the late response.
We are currently working on rebasing to release 0.18.
We plan to publish it in the near future, including the e2e tests that we implemented internally.

[cw-kojima1003]

I've opened a new PR, so I'll close this one.
Please leave any further comments on #3064.