-
Notifications
You must be signed in to change notification settings - Fork 4
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
Mount volume spec #22
Conversation
Signed-off-by: Jorge Aguilera <jagedn@gmail.com>
Signed-off-by: Jorge Aguilera <jagedn@gmail.com>
Signed-off-by: Jorge Aguilera <jagedn@gmail.com>
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 dear Jorge for finalizing this.
As discussed in our dev sync, I think we can now start the next phase of implementing other Nomad Job specs and map the Nextflow directives over them.
Excited to test a couple more pipelines with these changes! 🤩
Adding some context here regarding the current syntax for specifying the volume nomad {
client {
address = "http://NOMAD_IP:4646"
token = ""
}
jobs {
datacenters = "sun-nomadlab"
volume = { //final version is a closure, not a map
type "csi"
name "csi-volume-name"
}
}
}
|
Once we have the "asciidoctor/gh-pages/user guide" ready it will be a "requirement" to document this kind of stuff on it |
@jagedn , that makes sense. Just adding a thought for future reference, what if we want to allow the mounting multiple volumes within the same job? In that case, wouldn't it be easier to have Map oriented syntax, which can compose multiple volume-maps into an array specification. As shown below jobs {
datacenters = "sun-nomadlab"
volume = [
[
type: "csi" // CSI volume type - a volume shared across multiple client nodes
name: "csi-volume-name"
],
[
type: "host" // HOST volume type - maybe nomad client node specific block storage
name: "host-volume-name"
],
]
} This way we would keep the possibility of (multiple) HOST + CSI volumes into the same job definition and therefore allow a mix-n-match of node-specific and shared file systems for each task. What do you think? 🤔 |
close #13
This PR implements a new
volume
config where the user can specify thetype
and thename
of the volumeValid types are
host
,csi
anddocker
and the service create a JobSpec mounting itdockerVolume
is deprecated so the user must to use new configuration if want to mount a docker volumeWe've agreed only a volume is required, at least by the moment