-
Notifications
You must be signed in to change notification settings - Fork 182
Adding multipath-tools extension #505
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
base: main
Are you sure you want to change the base?
Adding multipath-tools extension #505
Conversation
|
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 |
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.
i don't think we need this, with mountPropogation shared should work as a normal extension service
| @@ -0,0 +1,1132 @@ | |||
| defaults { | |||
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.
this should be provided as an ExtensionServiceConfig
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.
this should just compile using base and put all libs under /rootfs/usr/local/lib/containers/multipath-tools/
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.
ok, sounds good, thanks
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.
@aaroncirillo-cision Any updates on this PR? I am looking to install multipath-tools as well and this would be very useful.
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.
@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
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.
there's also work to actually have /etc/iscsi/initiatorname.iscsi here: siderolabs/talos#10162 and some rework of iscsi-tools here: #577
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.
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
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.
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.
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.
@bzub @aaroncirillo-cision Anything we can do here?
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.
Created thread in Slack, for anyone interested:
https://taloscommunity.slack.com/archives/CG25RPZNE/p1740658131754019
|
This PR is stale because it has been open 45 days with no activity. |
|
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. |
|
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 |
|
@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 |
|
Okay so we could also probably use rook for the integration suite as it also supports multipath devices.. |
|
This PR is stale because it has been open 45 days with no activity. |
|
Has anyone been working on this lately and would be willing to collaborate? |
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.