Add flag -use-machined for Talos system extension

[bnason]

Flag '-use-machined' switches from using the TALOS_CONFIG_PATH and TALOS_HOST, to the Talos constants.MachineSocketPath at /system/run/machined/machine.sock. This is in support of creating a Talos system extension docker image to run talos-vmtoolsd as early in the boot process as possible.

Thanks to @flyik for the code inspiration.

[jonkerj]

Hi @bnason. As you might have heard, the repo changed hands, as @mologie is stepping away from using VMWare. We (Equinix) will take over from here, and we really like your approach. We will be working to get the tool compatible with recent Talos, and incorporate your suggestion/contribution, I'll be in touch.

[shkarface]

Hello @jonkerj , is there any update on this?

[robinelfrink]

Hi @bnason,

Would you please rebase on current master?

[bnason]

Hi @bnason,

Would you please rebase on current master?

Done, though I haven't done any testing yet.

[robinelfrink]

Would you please rebase on current master?

Done, though I haven't done any testing yet.

Thanks. However there are still some conflicts. Please leave all definitions out of Makefile as they are not used, except for SHA:

# For development only.
# This Makefile is not being used by Dockerfile or GitHub actions.

SHA ?= $(shell git describe --match=none --always --abbrev=8 --dirty)

talos-vmtoolsd:
    go build -ldflags="-s -w" -trimpath -o $@ ./cmd/$@

docker-build:
    docker buildx build . --tag talos-vmtoolsd:$(SHA) --file Dockerfile

docker-build-extension:
    docker buildx build . --tag talos-vmtoolsd-system-extension:$(SHA) --file system-extension/Dockerfile

.PHONY: talos-vmtoolsd docker-build

[robinelfrink]

Done, though I haven't done any testing yet.

I've tested your changes, and I got positive results:

$ talosctl get extensions
NODE         NAMESPACE   TYPE              ID   VERSION   NAME             VERSION
10.8.84.32   runtime     ExtensionStatus   0    1         talos-vmtoolsd   v0.5.0

[bnason]

Thanks. However there are still some conflicts. Please leave all definitions out of Makefile as they are not used, except for SHA:

If the version of the Makefile in my repo, everything I think is used except maybe 2 of them. These changes help build the images with the correct tags. My plan was/is to also setup GitHub actions to automatically publish the container images for git tags and these changes would help there.

If that is not something that is wanted, I can remove the changes.

Are the go.mod and go.sum conflicts an issue? (I'm not a go dev so those files are a mystery to me lol)

[robinelfrink]

If the version of the Makefile in my repo, everything I think is used except maybe 2 of them. These changes help build the images with the correct tags. My plan was/is to also setup GitHub actions to automatically publish the container images for git tags and these changes would help there.

The Makefile is not used for releases, it's only a tool for development. But if it helps you, just keep the definitions in.

Are the go.mod and go.sum conflicts an issue? (I'm not a go dev so those files are a mystery to me lol)

Yes, with conflicts we cannot merge :) You can recreate them easily during an interactive rebase:

$ git remote add upstream https://github.com/siderolabs/talos-vmtoolsd.git
$ git rebase -i upstream/master
Auto-merging Dockerfile
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Auto-merging go.mod
CONFLICT (content): Merge conflict in go.mod
Auto-merging go.sum
CONFLICT (content): Merge conflict in go.sum
[... edit Makefile to resolve conflicts there ...]
$ rm go.mod go.sum
$ go mod init github.com/siderolabs/talos-vmtoolsd
$ go mod tidy
$ git add Makefile go.mod go.sum
$ git rebase --continue
$ git push --force-with-lease

[bnason]

I see why I didn't have the same merge conflicts... My upstream was still pointing to Mologies repo