-
Notifications
You must be signed in to change notification settings - Fork 2k
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
dynamic host volumes: fingerprint client plugins #24589
Conversation
58cf6ba
to
06f577a
Compare
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've left some bikesheddy comments about the naming of user-facing attributes and some log levels, but otherwise this looks great!
command/agent/config.go
Outdated
@@ -229,6 +229,10 @@ type ClientConfig struct { | |||
// AllocMountsDir is the directory for storing mounts into allocation data | |||
AllocMountsDir string `hcl:"alloc_mounts_dir"` | |||
|
|||
// DHVPluginDir is the directory containing dynamic host volume plugins | |||
// db TODO(1.10.0): document default directory is alongside alloc_mounts | |||
DHVPluginDir string `hcl:"dhv_plugin_dir"` // db TODO(1.10.0): is this a good name? |
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.
For user-facing configuration/fields I don't love "dhv" over "host volume". Maybe host_volume_plugin_dir
?
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.
more bike-shedding;
- where should it go by default? I put it next to
alloc_mounts
because the intention is for the plugins to put stuff inalloc_mounts
, but it could go next to defaultplugin_dir
withindata_dir
instead? - I put
plugins-
as a prefix, so it would sort next to other "plugin" dirs, but none are present by default where I've put this, andhost-volume-plugins
would better match the config value... - default
-
-joinedplugins-host-volume
or_
plugins_host_volume
? - changing CLI flag to
-host-volume-plugin-dir
seems good, eh?
so many little fiddly naming bits 😅
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.
where should it go by default?
I'd follow the behavior we did for plugin_dir
where it's a child of data_dir
.
I put
plugins-
as a prefix, so it would sort next to other "plugin" dirs, but none are present by default where I've put this, andhost-volume-plugins
would better match the config value...
I don't have a super strong opinion on this so long as its unambiguous for other plugin dirs. I was going to ask what we did for CNI but that's the fairly ambiguous cni_path
🤦
default
-
-joinedplugins-host-volume
or_
plugins_host_volume
?
Definitely _
for HCL field values.
changing CLI flag to
-host-volume-plugin-dir
seems good, eh?
Yeah
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.
nice, I'll go with <data-dir>/host_volume_plugins
then. it won't be sorted next to plugins
, but I like the consistent word order in code and UX more than ls
output of the data dir. might even be good to type /opt/nomad/data/hos<tab><tab>
so autocomplete won't fight with plugins*
id, executable, targetPath string) (*HostVolumePluginExternal, error) { | ||
// this should only be called with already-detected executables, | ||
// but we'll double-check it anyway, so we can provide a tidy error message | ||
// if it has changed between fingerprinting and execution. |
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.
Nice catch on this.
wg.Add(1) | ||
go func(file, fullPath string) { | ||
defer wg.Done() | ||
// really should take way less than a second |
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.
Someone is totally going to write a plugin on the JVM that takes 10s to assemble a DI framework on startup, and we'll 🤦 about it. But this seems like a reasonable assumption. 😁
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.
yaknow, I wonder if plugin authors might even use the "responds to version
" aspect as a way to auto-disable plugins that won't be able to fulfill requests, like if they can't reach an NFS server, or who knows. they might want to try until some timeout, and that might reasonably be longer than 1s...
This finds executable files in a new
client.dhv_plugin_dir
that respond to a Version call (arg $1 =version
orOPERATION=version
env) with a valid version string on stdout, and adds them to the client fingerprint. This fingerprint responds to a SIGHUP.The main thing I'm wishy-washy on are user-facing names, which feel a bit franken-named here.
E.g.: given this client agent config
or this CLI call
and with these contents in that directory:
here are the client agent logs on sighup:
and this is the resulting fingerprint: