Skip to content

Update documentation with deploy script and other minor changes#256

Merged
Jakob-Naucke merged 2 commits into
trusted-execution-clusters:mainfrom
SpaceFace02:docs/COCL-362
May 21, 2026
Merged

Update documentation with deploy script and other minor changes#256
Jakob-Naucke merged 2 commits into
trusted-execution-clusters:mainfrom
SpaceFace02:docs/COCL-362

Conversation

@SpaceFace02
Copy link
Copy Markdown
Contributor

@SpaceFace02 SpaceFace02 commented May 14, 2026

Added deploy script + minor changes

Summary by Sourcery

Update the getting started guide to document a full one-shot deployment flow and required environment/setup steps for creating and using a kind-based cluster with the operator.

Enhancements:

  • Add a documented one-shot deploy bash script that automates cluster creation, KubeVirt and operator installation, and a sample VM deployment for quick end-to-end testing.

Documentation:

  • Expand the getting started guide with required environment variables, cluster cleanup and setup steps, KubeVirt installation, cluster readiness checks, and references to a new one-shot deploy script.

@sourcery-ai
Copy link
Copy Markdown

sourcery-ai Bot commented May 14, 2026

Reviewer's Guide

Updates the getting-started documentation to include explicit environment setup, cluster lifecycle steps, KubeVirt installation, and a new one-shot deployment script for quickly standing up a test environment.

Flow diagram for one-shot deploy script in getting-started guide

flowchart TD
  A[Start one-shot deploy script] --> B[Set environment exports
CONTAINER_CLI, RUNTIME
AK_REGISTRATION_ADDR
TRUSTEE_ADDR
REGISTRY]
  B --> C[make cluster-down]
  C --> D[make cluster-up]
  D --> E[make install-kubevirt]
  E --> F[make push]
  F --> G[make manifests]
  G --> H[make install]
  H --> I[kubectl -n trusted-execution-clusters get po,svc]
  I --> J[sleep 10m]
  J --> K[examples/create-ignition-secret.sh
examples/ignition-coreos.json
coreos-ignition-secret]
  K --> L[kubectl apply -f examples/vm-coreos-ign.yaml]
  L --> M[End]
Loading

File-Level Changes

Change Details Files
Clarified environment setup and cluster lifecycle steps for Kind-based installations.
  • Documented the need to set CONTAINER_CLI alongside RUNTIME for container runtime configuration.
  • Added explicit instruction to tear down any existing cluster with make cluster-down before creating a new one.
  • Separated and clarified the step for bringing the cluster up using make cluster-up.
docs/usage/getting-started-guide.md
Expanded operator installation instructions with KubeVirt installation, readiness waiting, and cluster status checks.
  • Added a step to install KubeVirt via make install-kubevirt before installing the operator.
  • Introduced an explicit wait (sleep 10m) for cluster readiness after installation.
  • Documented how to inspect operator-related resources with a kubectl get po,svc command in the target namespace.
  • Added a forward reference to a one-shot deploy script section for quicker installs once the manual process is understood.
docs/usage/getting-started-guide.md
Added a one-shot deploy bash script to automate the full local deployment flow for the trusted cluster operator.
  • Defined environment exports for Kind (CONTAINER_CLI, RUNTIME) and operator configuration (AK_REGISTRATION_ADDR, TRUSTEE_ADDR, REGISTRY).
  • Automated cluster cleanup and recreation including KubeVirt installation using make targets.
  • Automated operator build/push, manifest generation, and installation using make targets.
  • Automated post-installation checks, readiness wait, and creation of a sample VM via ignition secret and VM manifest application.
docs/usage/getting-started-guide.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

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

Hey - I've found 3 issues, and left some high level feedback:

  • The one-shot deploy script currently relies on a hardcoded sleep 10m; consider replacing this with a readiness check (e.g., kubectl wait or checking specific pods) so the script fails fast if the cluster or operator never becomes ready.
  • There are a few small typos in the new content (e.g., Kube-virt vs KubeVirt, oparator exports, deplyoed) that should be corrected for clarity and consistency.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The one-shot deploy script currently relies on a hardcoded `sleep 10m`; consider replacing this with a readiness check (e.g., `kubectl wait` or checking specific pods) so the script fails fast if the cluster or operator never becomes ready.
- There are a few small typos in the new content (e.g., `Kube-virt` vs `KubeVirt`, `oparator exports`, `deplyoed`) that should be corrected for clarity and consistency.

## Individual Comments

### Comment 1
<location path="docs/usage/getting-started-guide.md" line_range="91" />
<code_context>
 ```
 This example works with KubeVirt when the KBS is reachable using the pod networking.

+Make sure Kube-virt is also installed before trying to install the operator and testing functionality.
+```console
+make install-kubevirt
</code_context>
<issue_to_address>
**suggestion (typo):** Use the correct project name capitalization (KubeVirt).

Also remove the hyphen so it matches the upstream spelling.

```suggestion
Make sure KubeVirt is also installed before trying to install the operator and testing functionality.
```
</issue_to_address>

### Comment 2
<location path="docs/usage/getting-started-guide.md" line_range="115" />
<code_context>
+Refer to the one-shot deploy script at the end of this README for a quick install once you've understood the process.
+
 Further customization of the project can be controlled with the following env variables:
 + NAMESPACE: sets the namespace where the operator will be deplyoed
 + PLATFORM: use during the installation to configure the platform where the operator will be deployed (`kind` or `openshift`)
</code_context>
<issue_to_address>
**issue (typo):** Fix the typo in "deplyoed".

In the NAMESPACE description, update the word to "deployed".

```suggestion
+ NAMESPACE: sets the namespace where the operator will be deployed
```
</issue_to_address>

### Comment 3
<location path="docs/usage/getting-started-guide.md" line_range="176" />
<code_context>
+export CONTAINER_CLI=docker
+export RUNTIME=docker
+
+# oparator exports
+export AK_REGISTRATION_ADDR=attestation-key-register.trusted-execution-clusters.svc.cluster.local
+export TRUSTEE_ADDR=kbs-service.trusted-execution-clusters.svc.cluster.local
</code_context>
<issue_to_address>
**issue (typo):** Fix the misspelling of "operator" in this comment.

Currently spelled "oparator"; please correct it to "operator".

```suggestion
# operator exports
```
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
@SpaceFace02
Copy link
Copy Markdown
Contributor Author

SpaceFace02 commented May 14, 2026

@Jakob-Naucke For some reason I cannot add reviewers, unsure whether its a permission issue. Is /cc the correct way?

@SpaceFace02
Copy link
Copy Markdown
Contributor Author

/cc @Jakob-Naucke

@openshift-ci openshift-ci Bot requested a review from Jakob-Naucke May 14, 2026 07:34
@SpaceFace02
Copy link
Copy Markdown
Contributor Author

/cc @alicefr

@openshift-ci openshift-ci Bot requested a review from alicefr May 14, 2026 07:35
Copy link
Copy Markdown
Contributor

@Jakob-Naucke Jakob-Naucke left a comment

Choose a reason for hiding this comment

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

Thank you for the improvements! Some small comments.


Also make sure the container CLI environment variable is configured
```console
export CONTAINER_CLI=docker
Copy link
Copy Markdown
Contributor

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

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

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

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

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

Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated

Wait for cluster to be ready:
```console
sleep 10m
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

do we really need to put a sleep in the doc?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Something we could add is a Ready Condition in the TEC CR and wait for it. @Jakob-Naucke WDYT?

It exists, and it's on me for not thinking of it earlier…

Suggested change
sleep 10m
kubectl wait -n trusted-execution-clusters --for=condition=Installed TrustedExecutionCluster trusted-execution-cluster

Comment thread docs/usage/getting-started-guide.md
Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated
Copy link
Copy Markdown
Contributor

@Jakob-Naucke Jakob-Naucke left a comment

Choose a reason for hiding this comment

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

please also squash the removal and the sourcery suggestions commits

Comment thread docs/usage/getting-started-guide.md Outdated
Comment thread docs/usage/getting-started-guide.md Outdated

Wait for cluster to be ready:
```console
sleep 10m
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Something we could add is a Ready Condition in the TEC CR and wait for it. @Jakob-Naucke WDYT?

It exists, and it's on me for not thinking of it earlier…

Suggested change
sleep 10m
kubectl wait -n trusted-execution-clusters --for=condition=Installed TrustedExecutionCluster trusted-execution-cluster

@SpaceFace02
Copy link
Copy Markdown
Contributor Author

please also squash the removal and the sourcery suggestions commits

@Jakob-Naucke Just a side-note, Do we have the squash on merge enabled for this repo?

@Jakob-Naucke
Copy link
Copy Markdown
Contributor

please also squash the removal and the sourcery suggestions commits

@Jakob-Naucke Just a side-note, Do we have the squash on merge enabled for this repo?

It's enabled, but we've always created merge commits. So far, the practice has been to rewrite the history and force-push, so in the case of this PR, you'd squash the "Changes based on review comments" commit you've just added too (but we can also squash-and-merge just this one and you don't need to force-push if all's well). I prefer this approach because it makes reverts easier, even though it makes reviewing changes harder (but FWIW GitHub allows to view the changes by clicking the force-pushed in e.g. SpaceFace02 force-pushed the docs/COCL-362 branch). Maybe a discussion to have in #257 though.

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented May 21, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Jakob-Naucke, SpaceFace02

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

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

@Jakob-Naucke Jakob-Naucke merged commit f7b5b4d into trusted-execution-clusters:main May 21, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants