-
Notifications
You must be signed in to change notification settings - Fork 40
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
Add wasmCloud recipe #54
Conversation
Signed-off-by: Joonas Bergius <[email protected]>
Thank you for your contribution, @joonas ! I've tested the PR; first built the sysext
then started a fresh Flatcar qemu instance and provisioned the sysext (served from localhost). Butane config: variant: flatcar
version: 1.0.0
storage:
files:
- path: /etc/extensions/wasmcloud-0.82.0.raw
contents:
source: http://172.16.0.99:8000/wasmcloud-0.82.0.raw (172.16.0.99 was assigned to Ran a simple web server in the backend to serve the wasmcloud sysext, and started Flatcar with the above config (transpiled to JSON): python -m http.server &
./flatcar_production_qemu.sh -i wasmcloud.json -nographic
[...]
core@localhost ~ $ wasmcloud --version
wasmcloud 0.82.0 Looks good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @joonas for the contribution. What do you think about shipping the NATS systemd unit: https://github.com/nats-io/nats-server/blob/main/util/nats-server.service in the Sysext image? The NATS server could be automatically started when the sysext image is merged (same as sysext-bakery/create_kubernetes_sysext.sh Line 90 in 403e75f
|
That sounds great, I'll take a look at including default configuration. I had originally considered including unit files to start things out of the box, but I hesitated to include them since there is configuration you would likely want to pass in for the system to really be useful (consider the example of joining an existing cluster, for example). That being said, as I understand it should be pretty easy to customize and even completely override pre-existing unit files and/or configuration such that the node could be configured to be part of a larger pre-existing deployment, so including a default set of configuration that would effectively make this a single-node wasmCloud deployment out of the box for the purposes of things like demos and local development/kicking the tires is a fine starting point. I'm sure we can provide some docs with example butane/ignition configuration that'll override the defaults for including the provisioned node as part of an existing cluster setup. |
f401413
to
ec7a7ef
Compare
Per @tormath1's suggestion I've added a systemd unit file for For example: ---
variant: flatcar
version: 1.0.0
storage:
files:
- path: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
contents:
source: https://github.com/joonas/sysext-bakery/releases/download/latest/wasmcloud-0.82.0-x86-64.raw
- path: /etc/sysupdate.wasmcloud.d/wasmcloud.conf
contents:
source: https://github.com/joonas/sysext-bakery/releases/download/latest/wasmcloud.conf
- path: /etc/nats-server.conf
contents:
inline: |
jetstream {
domain: default
}
leafnodes {
remotes = [
{
url: "tls://connect.cosmonic.sh"
credentials: "/etc/nats.creds"
}
]
}
- path: /etc/nats.creds
contents:
inline: |
<redacted>
links:
- target: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
path: /etc/extensions/wasmcloud.raw
hard: false
systemd:
units:
- name: nats.service
enabled: true
dropins:
- name: 10-environment-override.conf
contents: |
[Service]
Environment=NATS_CONFIG=/etc/nats-server.conf
- name: wasmcloud.service
enabled: true
dropins:
- name: 10-environment-override.conf
contents: |
[Service]
Environment=WASMCLOUD_LATTICE=<redacted>
- name: systemd-sysupdate.timer
enabled: true
- name: systemd-sysupdate.service
dropins:
- name: wasmcloud.conf
contents: |
[Service]
ExecStartPre=/usr/lib/systemd/systemd-sysupdate -C wasmcloud update
- name: sysext.conf
contents: |
[Service]
ExecStartPost=systemctl restart systemd-sysext |
Co-authored-by: Kai Lüke <[email protected]>
Signed-off-by: Joonas Bergius <[email protected]>
Can you add the |
Sure can, are the changes in 157bbe2 in line with what you were thinking? |
157bbe2
to
ef31043
Compare
Awesome, thanks for helping me get this over the finish line folks! 🎉 |
Add wasmCloud recipe
This adds a new recipe for baking a wasmCloud sysext image.
How to use
Once the image is built, you can employ the following configuration ignition configuration (replacing
<your-repository-goes-here>
with the appropriate value) to consume it:Testing done
I've set up a testing branch on top of this branch to customize things ever so slightly to allow me to test using the above configuration on my own by pushing a
latest
tag to kick off CI and create a new "latest" release.Once I had a release ready to go, I ended up provisioning a DigitalOcean Droplet with Terraform loosely following Flatcar's docs to test the release.
When it was all said and done, I was able to successfully verify that the binaries and versions I would expect were indeed installed on the machine:
changelog/
directory (user-facing change, bug fix, security fix, update)/boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.Please note a couple more things:
release_build_versions.txt
, please let me know if you'd prefer I back those changes out and focus these changes on just the recipe.