Skip to content

Sync upstream Cloud API Adaptor v0.21.1 - #67

Open
yousef-cohere wants to merge 29 commits into
coherefrom
yousef/sync-upstream-v0.21.1
Open

Sync upstream Cloud API Adaptor v0.21.1#67
yousef-cohere wants to merge 29 commits into
coherefrom
yousef/sync-upstream-v0.21.1

Conversation

@yousef-cohere

Copy link
Copy Markdown

Summary

  • merge upstream Cloud API Adaptor v0.21.1 into the Cohere fork
  • preserve Cohere multi-provider chart, per-pod provider override, and configurable VXLAN MTU changes
  • align provider image references with the synchronized release

Test plan

  • Run CI unit and chart tests
  • Verify peerpods chart renders for single-provider and multi-provider configurations
  • Validate Cohere provider images build successfully

Made with Cursor

Amulyam24 and others added 25 commits May 22, 2026 14:06
Move the cluster provisioning to BYOM to remove the dependency on
the deprecated Docker provider.

Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
This commit adds extensive unit test coverage for the libvirt cloud provider,
while preserving all existing tests from the main branch.

New unit tests added (using mocks):
- TestGetGuestForArchType (6 subtests)
- TestLookupMachine (5 subtests)
- TestGetCanonicalMachineName (7 subtests)
- TestCreateCloudInitISO (3 subtests)
- TestGetLaunchSecurityTypeInvalidURI
- TestCreateDomainXMLs390xWithMocks (mock-based unit test)
- TestCreateDomainXMLaarch64WithMocks (mock-based unit test)
- TestCreateDomainXMLx86_64 (3 subtests)
- TestCreateDomainXML (3 subtests)
- TestVerifyDomainXMLIOMMU (4 subtests)

- Combined TestCreateDomainXMLs390x and TestCreateDomainXMLaarch64 into TestCreateDomainXMLArchitectures
- Combined TestCreateDomainXMLs390xWithMocks and TestCreateDomainXMLaarch64WithMocks into TestCreateDomainXMLArchitecturesWithMocks
- Improves code maintainability and reduces duplication

Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com>
Assisted-by: IBM Bob <noreply@ibm.com>
- Refactor TestCloudInit to use verifyISOContents helper and tabular format
- Combined TestCreateCloudInitWithEmptyData, TestCreateCloudInitWithLargeData, TestCreateCloudInitWithSpecialCharacters, and TestCreateCloudInitVerifyVendorData into TestCreateCloudInitVariations
- Add TestCreateCloudInitErrorHandling for boundary condition testing
- All tests now use verifyISOContents helper for consistent ISO validation
- Improves code maintainability and reduces duplication

Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com>
Assisted-by: IBM Bob <noreply@ibm.com>
- Add tests for Manager.ParseCmd() flag registration
- Add tests for Manager configuration with values
- Add tests for Manager.LoadEnv() and GetConfig()
- Add tests for Manager.NewProvider() with valid/invalid configs
- Add tests for default constants validation
- Add tests for launch security, firmware, and data directory configuration
- Covers all Manager initialization and configuration scenarios

Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com>
Assisted-by: IBM Bob <noreply@ibm.com>
Bumps [github.com/containerd/containerd](https://github.com/containerd/containerd) from 1.7.29 to 1.7.32.
- [Release notes](https://github.com/containerd/containerd/releases)
- [Changelog](https://github.com/containerd/containerd/blob/main/RELEASES.md)
- [Commits](containerd/containerd@v1.7.29...v1.7.32)

---
updated-dependencies:
- dependency-name: github.com/containerd/containerd
  dependency-version: 1.7.32
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Now that agent-ctl tags based on sha, we can switch to use the main
kata-containers version, rather than having a separate one.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump components to match the kata 3.31.0 release

Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update to pick up the 3.31.0 release

Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Pin kata-deploy to the 3.31.0 version in prep of the 0.21.0 release

Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bumps [zizmorcore/zizmor-action](https://github.com/zizmorcore/zizmor-action) from 0.5.3 to 0.5.6.
- [Release notes](https://github.com/zizmorcore/zizmor-action/releases)
- [Commits](zizmorcore/zizmor-action@b1d7e1f...5f14fd0)

---
updated-dependencies:
- dependency-name: zizmorcore/zizmor-action
  dependency-version: 0.5.6
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Bump the go module to remediate CVEs:
- GO-2026-5026
- GO-2026-4883

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump the go module to remediate CVEs:
- GO-2026-5013
- GO-2026-5017
- GO-2026-5018
- GO-2026-5019
- GO-2026-5020

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update the helm charts with the latest image of CAA

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
But the appVersion to 0.21 to match the release and bump
the version in peer-pods, peerpod-ctrl and webhook

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
The `kubectl apply` of the cert-manager manifest occasionally fails
with an etcd timeout:

```
Error from server: error when creating ".../cert-manager.yaml":
etcdserver: request timed out.
```

The manifest creates a large batch of resources (6 CRDs, RBAC,
deployments, webhook configs) in a single apply, and individual
writes can occasionally exceed the API server's request timeout
under transient cluster load.

Wrap the apply in a retry loop (3 attempts, 10s backoff). `kubectl
apply` is idempotent, so retrying after a partial failure simply
creates the missing resources without disturbing the ones already
applied. On the observed failing run, everything except (likely)
the last webhook config got created, and the retry will fill in the gap.

For `kubectl wait`, the Endpoints object isn't created by the cert-manager
manifest directly. It's created by the kube-controller-manager's endpoints
controller after the Service is created and once matching pods exist.
Right after `kubectl apply` returns, there's a brief window where the
Service exists but its Endpoints object hasn't been populated yet.
The apply just finished, so `kubectl wait` raced ahead of the controller.

Assisted-by: IBM Bob
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
The podvm-ubuntu-mkosi job calls podvm_mkosi_ubuntu.yaml which requires
artifact-metadata: write permission for the actions/attest@v4.1.0 action
to write attestation metadata. Without this permission, the workflow fails
with "The nested job 'build-image' is requesting 'artifact-metadata: write',
but is only allowed 'artifact-metadata: none'."

This matches the permission already granted to the podvm-mkosi job on line 84.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Generated-By: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Also added MKOSI_VERSION environment variable to image build steps in
both podvm_mkosi.yaml and podvm_mkosi_ubuntu.yaml workflows to ensure
the mkosi version from versions.yaml is explicitly passed to make
commands, maintaining consistency with the binaries build step.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Generated-By: IBM Bob
The image target was calling mkosi with '--image system' argument which
is not supported in mkosi v26, causing build failures with:
"mkosi: error: argument verb: invalid Verb value: 'system'"

This argument was a remnant from mkosi v22 that wasn't removed during
the v26 upgrade. The image-debug and image-sftp targets were already
correct, so this change aligns the image target with them.

Fixes the s390x production image builds.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Generated-By: IBM Bob
The cross-build script was failing on ARM64 native builds because it
compared ARCH=arm64 with uname -m=aarch64, which didn't match, causing
it to incorrectly attempt cross-compilation and fail with:
"E: Unable to locate package qemu-system-aarch64"

Added replacement pattern to handle this

Co-authored-by: Magnus Kulke <magnuskulke@microsoft.com>
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Generated-By: IBM Bob
Implement IRSA support for the AWS provider to enable workload identity
authentication on EKS, eliminating the need for static credentials stored
in Kubernetes secrets.

NewEC2Client now supports three authentication methods:
1. Static credentials (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY)
2. Shared AWS profile (AWS_PROFILE, currently, only non-containerized CAA binary execution is supported)
3. Default credential chain (for IRSA support)

The default credential chain automatically supports IRSA via AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN

Entrypoint validation updated to accept either:
- Both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (static credentials)
- AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN (IRSA)

Fixes: confidential-containers#3027
Signed-off-by: Snir Schreiber <ssheribe@redhat.com>
Assisted-by: Claude AI
Add unit tests to verify the two authentication paths in NewEC2Client:
1. Static credentials (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY)
2. Default credential chain (IRSA, IMDS, environment variables, etc.)

Tests cover:
- Static credentials path with both access key and secret key
- Default credential chain path when no static credentials provided
- Partial credentials (only access key) falls through to default chain

Assisted-by: Claude AI
Signed-off-by: Snir Schreiber <ssheribe@redhat.com>
Added comprehensive guide for configuring IRSA with cloud-api-adaptor
and peerpod-ctrl on Amazon EKS. The guide covers:
- IAM trust policy configuration
- Kubernetes service account annotations
- Deployment configuration examples
- Troubleshooting steps

Assisted-by: Claude AI
Signed-off-by: Snir Schreiber <ssheribe@redhat.com>
It looks like when the arm "support" for podvm builds was added, it wasn't
updated to use the native arm runner, so update this, for simpler workflows

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
In case we want to support cross-compilation in future e.g. for local dev,
fix up the logic.

The cross-build script was using architecture names directly as QEMU
package names, but Debian/Ubuntu package names don't always match:
- x86_64 → qemu-system-x86 (not qemu-system-x86_64)
- aarch64 → qemu-system-arm (not qemu-system-aarch64)
- s390x → qemu-system-s390x (matches)

Added architecture-to-package mapping for Debian/Ubuntu systems to use
correct package names. Package names verified against Ubuntu 24.04.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Assisted-by: IBM Bob
As we are doing a 0.21.1 release, we should update the charts to match this version.

Signed-off-by: stevenhorsman <steven@uk.ibm.com>
@yousef-cohere
yousef-cohere changed the base branch from cohere to yousef/configurable-overlay-mtu-stack July 31, 2026 20:04
@yousef-cohere
yousef-cohere force-pushed the yousef/sync-upstream-v0.21.1 branch from 506d116 to ac8c90f Compare July 31, 2026 20:12
@yousef-cohere
yousef-cohere force-pushed the yousef/configurable-overlay-mtu-stack branch from 158f488 to da264f5 Compare August 4, 2026 20:23
Base automatically changed from yousef/configurable-overlay-mtu-stack to cohere August 4, 2026 20:23
Comment thread src/cloud-api-adaptor/install/charts/peerpods/values.yaml

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit e1b95ae. Configure here.

Comment thread src/cloud-providers/Makefile
Comment thread src/cloud-providers/Makefile
Comment thread src/cloud-api-adaptor/test/provisioner/byom/provision_common.go
Preserve Cohere's reviewed multi-provider, annotation, and MTU changes while recording the upstream release as a true ancestor.

Co-authored-by: Cursor <cursoragent@cursor.com>
@yousef-cohere
yousef-cohere force-pushed the yousef/sync-upstream-v0.21.1 branch from e1b95ae to 19fb5a8 Compare August 5, 2026 18:31
Regenerate provider overrides, preserve the required upstream dev images, clean up BYOM clusters correctly, and update vulnerable Go dependencies and builders.

Co-authored-by: Cursor <cursoragent@cursor.com>
yousef-cohere and others added 2 commits August 6, 2026 10:43
Match upstream CAA RBAC so provider adaptors can resolve workload service accounts and image pull secrets across dynamic namespaces.

Co-authored-by: Cursor <cursoragent@cursor.com>
…-pull-rbac

fix(chart): restore private image credential access

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Identified one net-new security finding after module triage and deduplication.

Open in Web View Automation 

Sent by Cursor Security Agent: Security Reviewer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants