Skip to content

Conversation

@aaroncirillo-cision
Copy link

This PR adds a new extension for multipath-tools. This is needed in the environment I work in, and probably others as well.

I intend for this PR to be an open conversation about this feature. I tried to implement this in a way that aligns with Talos goals and philosophy, but if there is any feedback on this please let me know.

@aaroncirillo-cision
Copy link
Author

Where can I find the requirements for properly formatting my commit messages?

func main() {
fmt.Println("Starting multipath daemon...")

//setup a chroot environment for the extension
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 we need this, with mountPropogation shared should work as a normal extension service

@@ -0,0 +1,1132 @@
defaults {
Copy link
Member

Choose a reason for hiding this comment

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

this should be provided as an ExtensionServiceConfig

Copy link
Member

Choose a reason for hiding this comment

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

this should just compile using base and put all libs under /rootfs/usr/local/lib/containers/multipath-tools/

Choose a reason for hiding this comment

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

ok, sounds good, thanks

Copy link

Choose a reason for hiding this comment

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

@aaroncirillo-cision Any updates on this PR? I am looking to install multipath-tools as well and this would be very useful.

Choose a reason for hiding this comment

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

@lusrmgr
Not quite yet. I am running this extension internally right now and it is working for us. The extension I built was based on me grabbing binaries from Alpine and sticking them into an extension image. The Talos project can't accept that. They need a build from source integrated into their build system. So I do want to go back and clean up what I have and get a build running in their build system.

I've seen a few github threads on this topic actually. It looks like many of the CSI drivers for fiber channel arrays will have this same requirement. So getting this done would benefit everyone.

You may or may not have interest in the thread here as well discussing the same topic: hpe-storage/csi-driver#379

Copy link
Member

Choose a reason for hiding this comment

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

there's also work to actually have /etc/iscsi/initiatorname.iscsi here: siderolabs/talos#10162 and some rework of iscsi-tools here: #577

Copy link

@bzub bzub Jan 19, 2025

Choose a reason for hiding this comment

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

FWIW I've started working on this too. So far I've got multipath-tools compiling. The work in this PR is a huge help. I can submit a PR soon as well.

https://github.com/bzub/extensions/tree/multipath-tools

Choose a reason for hiding this comment

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

Your branch looks great, much better than what I did. I'm glad someone who had a better understanding of the build system took a look here. This was really my first encounter with Talos extensions and I was missing a lot of detail about how the bldr tool worked and how you could pull in dependencies from the core packages.

Choose a reason for hiding this comment

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

@bzub @aaroncirillo-cision Anything we can do here?

Choose a reason for hiding this comment

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

Created thread in Slack, for anyone interested:

https://taloscommunity.slack.com/archives/CG25RPZNE/p1740658131754019

@github-actions
Copy link

This PR is stale because it has been open 45 days with no activity.

@github-actions github-actions bot added the Stale label Jun 28, 2025
@k86td
Copy link

k86td commented Aug 19, 2025

hello! I just wanted to bump this PR, multipath is required in our environment (because of HPE CSI driver) and I was wondering if this is a dead end or if there's some activity in the background.

@github-actions github-actions bot removed the Stale label Aug 20, 2025
@frezbo
Copy link
Member

frezbo commented Aug 20, 2025

We can look into this as long as there's a reliable way to test this in our CI, someone needs to provide steps to test this

@oliverbaehler
Copy link

@frezbo What kind of result are you expecting from such a test/is there examples eg how you are testing the iscsi extension?

@frezbo
Copy link
Member

frezbo commented Aug 20, 2025

@frezbo What kind of result are you expecting from such a test/is there examples eg how you are testing the iscsi extension?

https://github.com/siderolabs/talos/blob/70612c1f9fc9056e8a3669ff10a385c4e8e03350/internal/integration/k8s/longhorn.go#L128 we have a test for iscsi using longhorn

@oliverbaehler
Copy link

Okay so we could also probably use rook for the integration suite as it also supports multipath devices..

@github-actions
Copy link

github-actions bot commented Oct 5, 2025

This PR is stale because it has been open 45 days with no activity.

@github-actions github-actions bot added the Stale label Oct 5, 2025
@Untersander
Copy link

Has anyone been working on this lately and would be willing to collaborate?
We need this extension for the Trident CSI (NetApp) to work in iSCSI mode.

@github-actions github-actions bot removed the Stale label Nov 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: On Hold

Development

Successfully merging this pull request may close these issues.

7 participants