Skip to content

Update documentation with deploy script and other minor changes #256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Jakob-Naucke merged 2 commits into from
May 21, 2026
Merged

Update documentation with deploy script and other minor changes #256

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dafab62
Update documentation with deploy script and other minor changes
SpaceFace02 May 14, 2026
33f7e9c
Changes based on review comments and sourcery suggestions
SpaceFace02 May 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 24 additions & 4 deletions docs/usage/getting-started-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,23 @@ Kind can be used with `docker` or `podman`. Although, we set `podman` as default
export RUNTIME=docker
```

The `CONTAINER_CLI` env var will used for building and pushing. If you require a non-Podman engine for building and pushing images, you can override it with the `$CONTAINER_CLI` variable.
```console
export CONTAINER_CLI=docker
Copy link
Copy Markdown
Contributor

@Jakob-Naucke Jakob-Naucke May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building should work fine on Podman -- did you find this to be necessary?

Copy link
Copy Markdown
Contributor Author

@SpaceFace02 SpaceFace02 May 15, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a line in the guide saying:

Kind can be used with docker or podman. Although, we set podman as default, right now there are some networking issues, therefore, the suggested runtime to use is docker at the moment. The runtime can be configured with:

So I went ahead and set default of runtime and container_cli to docker.

If the aforementioned issue is resolved, I'll change it to podman/CRI agnostic.

Copy link
Copy Markdown
Contributor

@Jakob-Naucke Jakob-Naucke May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes. CONTAINER_CLI is really just used for building and pushing, but this deserves clarification so let's maybe remove the paragraph but put this in its place:

If you require a non-Podman engine for building and pushing images, you can override it with the `$CONTAINER_CLI` variable.

Copy link
Copy Markdown
Contributor Author

@SpaceFace02 SpaceFace02 May 15, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

building and pushing can be either podman or docker, but for the runtime env variable? That has to be docker due to networking issues on podman?

Copy link
Copy Markdown
Contributor

@Jakob-Naucke Jakob-Naucke May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, that's what the paragraph just above is about

```

In order to interact with the cluster, `kubectl` is required.
```console
dnf install -y kubectl
```

Our kind cluster configuration is available under the `kind` directory and it uses the script `scripts/create-cluster-kind.sh`. The cluster can be simply created by running:
Our kind cluster configuration is available under the `kind` directory and it uses the script `scripts/create-cluster-kind.sh`.
Make sure any previously installed cluster is deleted before attempting to install a new one:
```console
make cluster-down
```

The cluster can be simply created by running:
```console
make cluster-up
```
Expand Down Expand Up @@ -75,15 +86,24 @@ export TRUSTEE_ADDR=kbs-service.trusted-execution-clusters.svc.cluster.local
export AK_REGISTRATION_ADDR=attestation-key-register.trusted-execution-clusters.svc.cluster.local

```
This example works with KubeVirt when the KBS is reachable using the pod networking.

Finally, the operator can be installed with:
```console
make install
```

Wait for cluster to be ready and in installed state:
```console
kubectl wait -n trusted-execution-clusters --for=condition=Installed TrustedExecutionCluster trusted-execution-cluster
```

Print cluster status
```console
kubectl -n trusted-execution-clusters get po,svc
Comment thread
SpaceFace02 marked this conversation as resolved.
```

Further customization of the project can be controlled with the following env variables:
+ NAMESPACE: sets the namespace where the operator will be deplyoed
+ NAMESPACE: sets the namespace where the operator will be deployed
+ PLATFORM: use during the installation to configure the platform where the operator will be deployed (`kind` or `openshift`)
+ INTEGRATION_TEST_THREADS: how many integration tests are run in parallel
+ REGISTRY: the registry used to publish the images
Expand Down Expand Up @@ -131,4 +151,4 @@ The attestation failing can be debugged by verifying the deployment of trustee.
kubectl logs -n trusted-execution-clusters <trustee-deplyoment>
```

In the logs, trustee prints the content of the TPM PCR registers. They need to match with the reference values present in the configmap `trustee-data` under `reference-values.json`.
In the logs, trustee prints the content of the TPM PCR registers. They need to match with the reference values present in the configmap `trustee-data` under `reference-values.json`.
2 changes: 2 additions & 0 deletions tests/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,8 @@ Upon a successful test, the namespace is cleaned up, otherwise it is kept for in
The tests use [`virtctl`](https://kubevirt.io/user-guide/user_workloads/virtctl_client_tool/) in order to interact with
VM, like getting the serial console and verifying that the guest has correctly booted by ssh-ing into it.

Other dependencies: *openssl-devel, gcc-c++*

N.B KubeVirt requires the cluster to be run as a privileged container on the host in order to handle the devices. Therefore, for now, we have moved to Docker with kind in order to generate the cluster. In the future, we might be able to move to rootful podman.

Run the tests locally with kind:
Expand Down