sysext: port AWS OEM to systemd sysext image #1083

tormath1 · 2023-08-24T14:29:17Z

In this PR, we port the current AWS OEM to a systemd system extension (sysext) image. It allows us to not rely on the base-ec2.ign configuration file and to remove specific OEM bits from the two related ebuilds: flatcar-eks and amazon-ssm-agent.

Testing done

CI: ⚙️ http://jenkins.infra.kinvolk.io:8080/job/container/job/packages_all_arches/2588/cldsv/
Flatcar EKS manual test (or automated)
Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

related to: flatcar/Flatcar#1145

github-actions · 2023-08-24T18:17:09Z

Build action triggered: https://github.com/flatcar/scripts/actions/runs/6297834375

pothos · 2023-08-25T10:31:19Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/files/manglefs.sh

+cat > "${rootfs}/usr/lib/systemd/system/setup-oem.service" <<-'EOF'
+[Unit]
+Description=Setup OEM
+


Should this run before amazon-ssm-agent.service?
Also, would symlinks work, too?

I'm curious: what would be the benefit of using symlink here? If the user wants to edit /etc/amazon/ssm/amazon-ssm-agent.json for example, he won't be able to do it as /usr/... is read-only.

With cp the user edits also get lost. With a symlink we could check whether a custom target is set and then don't touch it and document how that works to opt-out of auto-updates for that file.

pothos · 2023-08-25T10:34:36Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ec2-compat/files/base/base-ec2.ign can be deleted and ec2 removed from oem-ec2-compat-0.1.2-r3.ebuild.
We also need the list of old OEM files to clean up for the migration (for the rootfs only /etc/systemd/system/amazon-ssm-agent.service and its enabling symlink?).

pothos · 2023-08-25T10:35:37Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/files/manglefs.sh

+EOF
+
+mkdir -p "${rootfs}/usr/lib/systemd/system/multi-user.target.d"
+{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service coreos-metadata-sshkeys@.service setup-oem.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ami.conf"


Enabling coreos-metadata-sshkeys@.service is something we should do in the base image.

pothos · 2023-08-25T12:00:39Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/files/manglefs.sh

+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStartPre=/usr/bin/cp /usr/share/amazon/ssm/amazon-ssm-agent.json /etc/amazon/ssm/amazon-ssm-agent.json.template


If that file is only used by the service unit we could also use BindPaths= to provide it under /etc. @krnowak that could also be an option for the waagent, or?

pothos · 2023-08-30T16:56:42Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ec2/files/manglefs.sh

+  /etc/eks/bootstrap.sh
+)
+
+rm -rf "${to_delete[@]/#/${rootfs}}"


I don't understand this line, what creates the files under /etc?

Sorry, I've been confused about the manglefs script - to me it was running on the host so I wanted to clean up the OEM old files from there.

EDIT: Ok, it's done there flatcar/update_engine#24 (comment)

The list of old OEM files should now go to the misc-files package: #1016
We should boot an instance and check the old contents of /oem/ (the list of files for /etc looks good and can be easily seen in the base.ign).

So, the above can be deleted here, or?

pothos · 2023-08-30T16:58:14Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ec2/files/manglefs.sh

+mkdir -p "${rootfs}/usr/lib/systemd/system/amazon-ssm-agent.service.d"
+cat > "${rootfs}/usr/lib/systemd/system/amazon-ssm-agent.service.d/10-bindpaths.conf" <<-'EOF'
+[Service]
+BindPaths=/usr/share/amazon/ssm/:/etc/amazon/ssm/ /usr/share/amazon/eks/boostrap.sh:/etc/eks/bootstrap.sh


Are users expected to be able run the CLI themselves and does it also read from /etc? (In that case we would anyway have to have the symlinks from /etc, or?)

Actually from my understanding, the bootstrap script is executed by user-data (https://kinvolk.io/blog/2021/02/deploying-an-eks-cluster-with-flatcar-workers/) - so it does not even need to be shared

My question was more about ssm-cli and whether this is used by users and needs access to the files in /etc.

It seems that ssm-cli is consuming directly the amazon-ssm-agent but I think it might be wiser to copy directly the files in /etc rather that bind mount.

pothos · 2023-08-31T08:27:05Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ec2/files/manglefs.sh

+EOF
+
+mkdir -p "${rootfs}/usr/lib/systemd/system/multi-user.target.d"
+{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service coreos-metadata-sshkeys@core.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf"


Can we do the starting of coreos-metadata-sshkeys@core.service in the base image - we also do the coreos-cloudinit start in the base image and could do it similarly (have a unit that has a condition for the the OEM kernel cmdline argument and then uses Upholds= to start it).

Something like this

[Unit] ConditionKernelCommandLine=|ignition.platform.id=packet ConditionKernelCommandLine=|flatcar.oem.id=packet ConditionKernelCommandLine=|coreos.oem.id=packet ConditionKernelCommandLine=|ignition.platform.id=ec2 ConditionKernelCommandLine=|flatcar.oem.id=ec2 ConditionKernelCommandLine=|coreos.oem.id=ec2 ConditionKernelCommandLine=|ignition.platform.id=digitalocean ConditionKernelCommandLine=|flatcar.oem.id=digitalocean ConditionKernelCommandLine=|coreos.oem.id=digitalocean ConditionKernelCommandLine=|ignition.platform.id=gce ConditionKernelCommandLine=|flatcar.oem.id=gce ConditionKernelCommandLine=|coreos.oem.id=gce Upholds=coreos-metadata-sshkeys@core.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/true [Install] WantedBy=multi-user.target

Suggested change

{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service coreos-metadata-sshkeys@core.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf"

{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf"

Interesting - the Upholds units are executed unconditionally:

$ systemctl status sshkeys@core.service ○ sshkeys@core.service Loaded: loaded (/usr/lib/systemd/system/sshkeys@.service; static) Active: inactive (dead) Condition: start condition failed at Fri 2023-09-08 12:14:19 UTC; 17min ago Sep 08 12:14:19 localhost systemd[1]: sshkeys@core.service was skipped because no trigger condition checks were met. $ systemctl status coreos-metadata-sshkeys@core.service ● coreos-metadata-sshkeys@core.service - Flatcar Metadata Agent (SSH Keys) Loaded: loaded (/usr/lib/systemd/system/coreos-metadata-sshkeys@.service; disabled; preset: disabled) Active: activating (auto-restart) (Result: exit-code) since Fri 2023-09-08 12:34:50 UTC; 7s ago Process: 1799 ExecStart=/usr/bin/coreos-metadata ${COREOS_METADATA_OPT_PROVIDER} --ssh-keys=core (code=exited, status=1/FAILURE) Main PID: 1799 (code=exited, status=1/FAILURE) CPU: 11ms

-> whole qemu test suite is failing. I guess we can go back to ExecStart=systemctl start coreos-metadata-sshkeys@core.service

What are the contents of /usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf? Is this really the most recent state?

Ah, understood, so it seems the condition is only for the [Service] section? And Upholds= still gets used all the time. Then yes, ExecStart=systemctl start coreos-metadata-sshkeys@core.service instead of ExecStart=/bin/true sounds good!

What are the contents of /usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf? Is this really the most recent state?

It's for qemu so the sysext image is not even present.

so it seems the condition is only for the [Service] section?

That's my conclusion too.

Ok, so more follow-up for the init PR… Sorry for the misleading suggestion

No worries - I fixed this right after: flatcar/init#105 now the CI is 🟢

pothos · 2023-09-07T15:00:02Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ec2/files/manglefs.sh

+ExecStartPre=/usr/bin/ln --symbolic /usr/share/amazon/ssm/amazon-ssm-agent.json.template /etc/amazon/ssm/amazon-ssm-agent.json
+ExecStartPre=/usr/bin/ln --symbolic /usr/share/amazon/ssm/seelog.xml.template /etc/amazon/ssm/seelog.xml
+ExecStart=/usr/bin/ln --symbolic /usr/share/amazon/eks/bootstrap.sh /etc/eks/bootstrap.sh


When the link already exists this will fail, do you want it to be skipped then? This would be possible with ExecStartPre=-.

I think we should talk about this: how we manage the update of /etc. While redoing this section, I was thinking about using cp --backup to a) update the /etc/ files and b) keep any previous configuration.

Since these files are likely touched by the user I would exclude them from the migration step. This means they will be there as regular files and not updated unless we could identify them as untouched with a checksum and create the symlink. For new instances the symlink is the default and we don't need to do a update logic and this is covered by the sysext content. The user could still overwrite the symlink or replace it with a file if we use ExecStartPre=-.

pothos · 2023-09-25T09:43:20Z

Of course, we can keep the OEM ID in the oem-release file to be ami but we still need to translate it somewhere to ec2 or aws for afterburn.

The oem release ID would only be used for the update payload name and the migration file. No translation to ec2 or aws is required.

tormath1 · 2023-09-25T10:04:17Z

Of course, we can keep the OEM ID in the oem-release file to be ami but we still need to translate it somewhere to ec2 or aws for afterburn.

The oem release ID would only be used for the update payload name and the migration file. No translation to ec2 or aws is required.

For this one yes, no translation but we still need one for the kernel command line parameter (see: 9df7e19). Otherwise ami is unknown for Ignition and Afterburn, while it can still be supported by Ignition via ignition-generator, Afterburn expects to find ec2 or aws.

pothos · 2023-09-25T12:44:00Z

changelog/changes/2023-08-30-sysext-for-aws-oem.md

+- AWS OEM images now use a systemd-sysext image for layering additional platform-specific software on top of `/usr`. The OEM software is still not updated but this will be added soon.
+- The AWS OEM ID kernel command line parameter changed to `ami`


Suggested change

- AWS OEM images now use a systemd-sysext image for layering additional platform-specific software on top of `/usr`. The OEM software is still not updated but this will be added soon.

- The AWS OEM ID kernel command line parameter changed to `ami`

- AWS OEM images now use a systemd-sysext image for layering additional platform-specific software on top of `/usr`

pothos · 2023-09-25T12:52:07Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/files/10-oem-ami.conf

@@ -0,0 +1,2 @@
+[Unit]
+Upholds=amazon-ssm-agent.service


Suggested change

Upholds=amazon-ssm-agent.service

Upholds=amazon-ssm-agent.service setup-oem.service

pothos · 2023-09-25T12:59:31Z

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/oem-ami-3.2.985.0-r1.ebuild

+
+src_install() {
+	systemd_dounit "${FILESDIR}/setup-oem.service"
+	systemd_install_serviced "${FILESDIR}/10-oem-ami.conf" multi-user.target


Is this line correct? I don't see the service running

Even after starting manually I think it has some problems:

Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:41 WARN [ssm-agent-worker] failed to read runtime config 'identity_config.json': open /var/lib/amazon/ssm/runtimeconfig/identity_config.json: no such file or directory Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:41 INFO [ssm-agent-worker] Checking if agent identity type CustomIdentity can be assumed Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:41 WARN [ssm-agent-worker] failed to read runtime config 'identity_config.json': open /var/lib/amazon/ssm/runtimeconfig/identity_config.json: no such file or directory Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:41 ERROR [ssm-agent-worker] Agent failed to assume any identity Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:41 ERROR [ssm-agent-worker] failed to find identity, retrying: failed to find agent identity Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 INFO [ssm-agent-worker] Checking if agent identity type OnPrem can be assumed Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 WARN [ssm-agent-worker] failed to read runtime config 'identity_config.json': open /var/lib/amazon/ssm/runtimeconfig/identity_config.json: no such file or directory Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 INFO [ssm-agent-worker] Checking if agent identity type EC2 can be assumed Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 WARN [ssm-agent-worker] failed to read runtime config 'identity_config.json': open /var/lib/amazon/ssm/runtimeconfig/identity_config.json: no such file or directory Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 INFO [ssm-agent-worker] Checking if agent identity type CustomIdentity can be assumed Sep 25 13:01:42 ip-172-31-31-92.us-west-2.compute.internal amazon-ssm-agent[2368]: 2023-09-25 13:01:42 WARN [ssm-agent-worker] failed to read runtime config 'identity_config.json': open /var/lib/amazon/ssm/runtimeconfig/identity_config.json: no such file or directory

If the termination also happens on the latest Alpha it can be ignored

Is this line correct? I don't see the service running

The file is actually installed in /etc/systemd/system/multi-user.target.d/ so it's not packaged.

krnowak

Some nitpicks.

...tainer/src/third_party/coreos-overlay/coreos-base/common-oem-files/common-oem-files-0.ebuild

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/oem-ami-3.2.985.0-r1.ebuild

sdk_container/src/third_party/coreos-overlay/coreos-base/misc-files/files/oems/ami

krnowak

Just remembered about revision bumping in overlay.

...tainer/src/third_party/coreos-overlay/coreos-base/common-oem-files/common-oem-files-0.ebuild

...container/src/third_party/coreos-overlay/coreos-base/flatcar-eks/flatcar-eks-0.0.1-r1.ebuild

sdk_container/src/third_party/coreos-overlay/coreos-base/misc-files/files/oems/ami

...ner/src/third_party/coreos-overlay/coreos-base/oem-ec2-compat/oem-ec2-compat-0.1.2-r3.ebuild

sdk_container/src/third_party/coreos-overlay/coreos-base/oem-ami/oem-ami-3.2.985.0-r1.ebuild

- drop the OEM mention - install things under /usr/share/amazon/ssm - add systemd unit from the upstream Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

while this ebuild will be dropped in the near future, we still need to maintain openstack ebuild. `flatcar-eks` was a runtime dependency of openstack/brightbox too. I think it was a mistake ? Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

found by booting stable on AWS: `find /usr/share/oem` + checking the content of files created by base Ignition. Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

...ner/src/third_party/coreos-overlay/coreos-base/common-oem-files/common-oem-files-0-r1.ebuild

For this vendor, the OEM ID from the oem-release file is different from the oem.id kernel commandline parameter. Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

krnowak

Cool, looks good from my side.

pothos

Thanks!

tormath1 self-assigned this Aug 24, 2023

tormath1 temporarily deployed to development August 24, 2023 14:29 — with GitHub Actions Inactive

tormath1 had a problem deploying to development August 25, 2023 07:03 — with GitHub Actions Error

tormath1 had a problem deploying to development August 25, 2023 09:11 — with GitHub Actions Error

pothos reviewed Aug 25, 2023

View reviewed changes

tormath1 had a problem deploying to development August 28, 2023 10:06 — with GitHub Actions Error

tormath1 force-pushed the tormath1/oem branch from 56ee0c3 to 41c4ff2 Compare August 29, 2023 12:51

tormath1 had a problem deploying to development August 29, 2023 12:51 — with GitHub Actions Error

tormath1 had a problem deploying to development August 30, 2023 07:31 — with GitHub Actions Error

tormath1 force-pushed the tormath1/oem branch from aedb47f to 2fe2a5c Compare August 30, 2023 11:56

tormath1 had a problem deploying to development August 30, 2023 11:56 — with GitHub Actions Error

tormath1 force-pushed the tormath1/oem branch from 2fe2a5c to 5b7f443 Compare August 30, 2023 12:18

tormath1 had a problem deploying to development August 30, 2023 12:18 — with GitHub Actions Error

tormath1 force-pushed the tormath1/oem branch from 5b7f443 to 7834df4 Compare August 30, 2023 15:57

tormath1 had a problem deploying to development August 30, 2023 15:57 — with GitHub Actions Error

tormath1 had a problem deploying to development August 30, 2023 16:00 — with GitHub Actions Error

tormath1 marked this pull request as ready for review August 30, 2023 16:00

tormath1 requested a review from a team August 30, 2023 16:00

pothos reviewed Aug 30, 2023

View reviewed changes

pothos reviewed Aug 31, 2023

View reviewed changes

tormath1 force-pushed the tormath1/oem branch from 9016250 to 8841684 Compare September 7, 2023 13:36

tormath1 had a problem deploying to development September 7, 2023 13:36 — with GitHub Actions Error

tormath1 mentioned this pull request Sep 7, 2023

systemd/system: add sshkeys@.service flatcar/init#103

Merged

pothos reviewed Sep 7, 2023

View reviewed changes

tormath1 force-pushed the tormath1/oem branch from 8841684 to 957cd43 Compare September 8, 2023 07:37

pothos reviewed Sep 25, 2023

View reviewed changes

tormath1 force-pushed the tormath1/oem branch from ec04512 to 57718ba Compare September 26, 2023 08:04

tormath1 had a problem deploying to development September 26, 2023 08:04 — with GitHub Actions Error

tormath1 force-pushed the tormath1/oem branch from 57718ba to d703e00 Compare September 26, 2023 08:36

tormath1 had a problem deploying to development September 26, 2023 08:36 — with GitHub Actions Error

krnowak reviewed Sep 26, 2023

View reviewed changes

tormath1 added 7 commits September 26, 2023 13:34

overlay app-emulation/amazon-ssm-agent: remove oem spec

8ba940b

- drop the OEM mention - install things under /usr/share/amazon/ssm - add systemd unit from the upstream Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

overlay coreos-base/flatcar-eks: remove oem spec

735dfb4

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

overlay coreos-base/common-oem-files: add grub EC2

fbc1906

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

overlay coreos-base/oem-ami: new sysext image

ce2c0e7

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

changelog: add entry

50e6da3

Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

overlay coreos-base/misc-files: add ami oem files

79b0751

found by booting stable on AWS: `find /usr/share/oem` + checking the content of files created by base Ignition. Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

tormath1 force-pushed the tormath1/oem branch from d703e00 to 678c8fc Compare September 26, 2023 11:35

tormath1 had a problem deploying to development September 26, 2023 11:35 — with GitHub Actions Error

krnowak reviewed Sep 26, 2023

View reviewed changes

...ner/src/third_party/coreos-overlay/coreos-base/common-oem-files/common-oem-files-0-r1.ebuild Outdated Show resolved Hide resolved

overlay coreos-base/common-oem-files: translate ami to ec2

bfaea38

For this vendor, the OEM ID from the oem-release file is different from the oem.id kernel commandline parameter. Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>

tormath1 force-pushed the tormath1/oem branch from 678c8fc to bfaea38 Compare September 26, 2023 12:55

tormath1 had a problem deploying to development September 26, 2023 12:55 — with GitHub Actions Failure

krnowak approved these changes Sep 26, 2023

View reviewed changes

pothos approved these changes Sep 26, 2023

View reviewed changes

tormath1 merged commit 6c61372 into main Sep 26, 2023
1 check failed

tormath1 deleted the tormath1/oem branch September 26, 2023 15:03

pothos mentioned this pull request Sep 26, 2023

Enable updating of OEM specific tools flatcar/Flatcar#60

Closed

10 tasks

github-actions bot mentioned this pull request Nov 9, 2023

Monthly contributions report 2023-09-22 - 2023-10-21 flatcar/Flatcar#1244

Closed

	{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service coreos-metadata-sshkeys@core.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf"
	{ echo "[Unit]"; echo "Upholds=amazon-ssm-agent.service"; } > "${rootfs}/usr/lib/systemd/system/multi-user.target.d/10-oem-ec2.conf"

		- AWS OEM images now use a systemd-sysext image for layering additional platform-specific software on top of `/usr`. The OEM software is still not updated but this will be added soon.
		- The AWS OEM ID kernel command line parameter changed to `ami`

	Upholds=amazon-ssm-agent.service
	Upholds=amazon-ssm-agent.service setup-oem.service

sysext: port AWS OEM to systemd sysext image #1083

sysext: port AWS OEM to systemd sysext image #1083

Conversation

tormath1 commented Aug 24, 2023 • edited Loading

Testing done

github-actions bot commented Aug 24, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pothos commented Aug 25, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tormath1 Aug 31, 2023 • edited Loading

Choose a reason for hiding this comment

pothos Aug 31, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tormath1 Sep 8, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pothos commented Sep 25, 2023

tormath1 commented Sep 25, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

krnowak left a comment

Choose a reason for hiding this comment

krnowak left a comment

Choose a reason for hiding this comment

krnowak left a comment

Choose a reason for hiding this comment

pothos left a comment

Choose a reason for hiding this comment

tormath1 commented Aug 24, 2023 •

edited

Loading

github-actions bot commented Aug 24, 2023 •

edited

Loading

pothos commented Aug 25, 2023 •

edited

Loading

tormath1 Aug 31, 2023 •

edited

Loading

pothos Aug 31, 2023 •

edited

Loading

tormath1 Sep 8, 2023 •

edited

Loading