Skip to content
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.

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

feat(*): add node installer dir and workflow #26

Merged
merged 4 commits into from
Mar 11, 2024

Conversation

vdice
Copy link
Contributor

@vdice vdice commented Mar 6, 2024

  • Adds node-installer.yaml to publish a custom node installer image with only the Spin shim baked in
    • Call this workflow for both PRs (ci.yaml) and main/tag release (release.yaml)
  • Also run release.yaml on merges to main (albeit sans GH release when push to main)
  • Update RELEASE_VERSION logic to support other refs (eg refs/heads/main where the 10 char split breaks)

I believe the intention is to eventually have spinkube/runtime-class-manager produce this image via fetching versioned shim releases from this repo, but this gets us an image with the latest shim version that we/users can plug in when installing the kwasm-operator chart, near-term.

Tested on fork eg https://github.com/vdice/containerd-shim-spin/actions/runs/8181643173

kwasm-node-installer/Dockerfile Outdated Show resolved Hide resolved
@Mossaka
Copy link
Member

Mossaka commented Mar 6, 2024

nit: consider renaming kwasm to runtime class manager

@vdice
Copy link
Contributor Author

vdice commented Mar 6, 2024

@Mossaka agreed it might be better to use a different name. Slightly hesitant to use runtime-class-manager since https://github.com/spinkube/runtime-class-manager in its current form appears to hold the operator logic as opposed to the node-installer logic... what about shim-node-installer here; or just node-installer? The latter as oci ref would be something like ghcr.io/spinkube/containerd-shim-spin/node-installer. Thoughts?

@radu-matei
Copy link
Member

Would it be possible to generate the node installer image on PRs as well?
It would be fantastic to be able to create a test cluster based on a not yet merged branch, and not have to build everything yourself.

@vdice
Copy link
Contributor Author

vdice commented Mar 6, 2024

Would it be possible to generate the node installer image on PRs as well?

We could; working on a re-org to support this. As a follow-up in the future, if we wanted, we could also push the k3d img on PRs while we are at it.


RUN mkdir -p /release/bin/ \
&& curl -L https://github.com/containerd/runwasi/releases/download/containerd-shim-wasmedge%2Fv0.3.0/containerd-shim-wasmedge-$(uname -m | sed s/arm64/aarch64/g | sed s/amd64/x86_64/g).tar.gz | tar -xzf - -C /release/bin/ \
&& curl -L https://github.com/containerd/runwasi/releases/download/containerd-shim-wasmtime%2Fv0.3.0/containerd-shim-wasmtime-$(uname -m | sed s/arm64/aarch64/g | sed s/amd64/x86_64/g).tar.gz | tar -xzf - -C /release/bin/ \
Copy link
Member

Choose a reason for hiding this comment

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

One point I want to raise here is — this is the custom node installer image for SpinKube and the Spin operator project, and we generate this image from the Spin shim.

I'd like to propse that this image only configures the Spin shim, for a number of reasons:

  • the other shims are not used by SpinKube
  • we are not updating them as part of this installer
  • we might actually overwrite someone's desired other shim version
  • they represent a security vulnerability area that is unnecessary because of the first two points

Managing other shims and runtime classes is the job for https://github.com/spinkube/runtime-class-manager/, and configuration there IMO is where someone would decide to bring in another shim.

@vdice
Copy link
Contributor Author

vdice commented Mar 7, 2024

In the latest commits:

@vdice vdice changed the title feat(*): add kwasm-node-installer dir, add publishing steps to release.yaml feat(*): add node installer dir and workflow Mar 7, 2024
@vdice
Copy link
Contributor Author

vdice commented Mar 7, 2024

Looks like the workflow can't push the node-installer image, probably due ro running from a PR. Is there a setting we can toggle to allow publishing packages from PRs? Or perhaps I need to create the branch on origin and not my fork?

 buildx failed with: ERROR: failed to solve: failed to push ghcr.io/spinkube/containerd-shim-spin/node-installer:20240307-033658-g6a41bf5: unexpected status from POST request to https://ghcr.io/v2/spinkube/containerd-shim-spin/node-installer/blobs/uploads/: 403 Forbidden

Edit: Yes, images (packages) can only be published when the PR branch is on origin. (See #30 and https://github.com/spinkube/containerd-shim-spin/actions/runs/8191813640/job/22403982746?pr=30). I assume that's our desired state as opposed to allowing PRs from forks to publish packages - if even possible. Hence, I've gated the job appropriately in 198e74f. cc @radu-matei

Edit 2: Actually, my attempt at gating the job if a PR is from a fork isn't working as expected; looking...

@Mossaka
Copy link
Member

Mossaka commented Mar 7, 2024

Yeah node-installer sounds good to me

@vdice
Copy link
Contributor Author

vdice commented Mar 7, 2024

@radu-matei I don't see a great way to gate the node-installer image push job to only running when the PR is from a branch on origin, rather than a fork. The workaround to publish custom node-installer images from code changes not on main would be to push to the main branch of one's fork where the code changes are. Would this suffice near-term? If so, I'd remove logic to publish the image on PRs; we can revisit in the future.

Edit: wait, trying one more thing... yup 167ab94 works to only push the image if PR branch is on origin.

Copy link
Member

@Mossaka Mossaka left a comment

Choose a reason for hiding this comment

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

LGTM

uses: ./.github/workflows/node-installer.yaml
needs: build
# This action requires use of the GITHUB_TOKEN to publish the image
# By default, PRs from forks don't have access, so we only run when the PR branch is on origin.
Copy link
Member

Choose a reason for hiding this comment

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

Does this imply that maintainers of this project should push feat branches to origin?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. Should I add a mention of this in other areas as well? Maybe the README?

Copy link
Member

Choose a reason for hiding this comment

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

I don't think it's necessary to put it in the README

Copy link
Collaborator

@kate-goldenring kate-goldenring left a comment

Choose a reason for hiding this comment

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

LGTM!

@kate-goldenring kate-goldenring merged commit 1f8c36a into spinkube:main Mar 11, 2024
8 of 9 checks passed
@vdice vdice deleted the ci/kwasm-node-installer branch March 11, 2024 14:29
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.

4 participants