-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Add a field to the config file for plugin use. #1652
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1652 +/- ##
==========================================
+ Coverage 56.07% 56.11% +0.04%
==========================================
Files 306 306
Lines 20997 21019 +22
==========================================
+ Hits 11774 11795 +21
+ Misses 8373 8370 -3
- Partials 850 854 +4 |
@ijc so, this would be configuration options for a plugin, right? Some quick thoughts;
{
"Plugins": {
"hello": {
"foobar": {
"nestedfoobar" : {
"centre-of-earth": true
}
},
"bla": ["one", "two", "three"]
}
}
} I know at the API level, we have options for plugins, and limit those to Another thing I'm wondering is; Do we want plugins to use separate files, so that it's easier to;
One note to add; we should rethink our configuration file format(s) (in general). JSON is great, but (e.g.) doesn't allow for annotated versions, which sometimes limits its use (i.e., we cannot ship a "sample" configuration file), and JSON is not always that user-friendly Related: #1622, moby/moby#20151 |
Yes, that's the trade off between this or plugin authors having to patch docker/cli to add their custom fields. I think we should assume that plugin authors are generally sensible.
I think having a single file is nicer for users and the integration is a feature. In particular plugins are encouraged to use global config from There some more stuff on this in the design (#1534) which said explicitly that the config should be in a single file. |
That seems way out of scope for the particular change here. |
Would making it a {
"Plugins": {
"myplugin.option1": "value",
"myplugin.option2": "value",
}
} or {
"Plugins": {
"myplugin": {
"option1": "value",
"option2": "value"
}
}
} |
Yes, I think a single file could work for now
The change itself is definitely out of scope, but meant to say; try to keep it format agnostic, as JSON may become something else at some point (IOW, we should try and store the configuration itself in a known format, and not literal JSON) |
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.
LGTM
It'd work, but would mean plugins having to invent syntax for various structured stuff. So not ideal (but better than nothing). Maybe it's not a huge deal for the sorts of settings we imagine there being. Lists are annoying though since you need a separator, which means you need escaping etc. I suppose helpers might be the answer.
Perhaps this calls for the helpers/accessors I hypothesised in the commit message getting pull forward, so there would be
which abstracts the use of The thing passed as config would still potentially need to have the |
Argh, thought I replied;
Not sure I grasp this fully; my main thought was to limit the struct for per-plugin configuration to a
Should the first example return the This could potentially be extended to; func (ConfigFile *c) PluginConfig(pluginname string, option string) So, e.g. {
"Plugins": {
"myplugin": {
"some-option": "foo"
}
} Regarding |
What I meant was that if a plugin has a list of things to store (
Not in what I was prpoposing, since you need to pass in a concrete thing (a func (ConfigFile *c) PluginConfig(pluginname string, config reflect.Type) interface{} but that's pretty awful. Your proposal is slightly different since it takes a single named option for which it returns the value. That would work too. It's a bit flat and I would expect to see plugins working around this with Perhaps I'm over thinking this and we should go with a simple option (e.g. |
I think we need more feedback from the plugin developers themselves and see if they really need complex configuration struct or juste few feature flags. My 2cts is they don't really need something complex and just a My other 2cts is that changing afterwards from a |
Yep, that was what I was trying to say with "is possible, the opposite isn't". I will rework this PR to use the |
Thanks! Yes, that was basically my train of thought as well; for daemon drivers (logging, storage-drivers) we went for a simple |
OK, I switched to a simple |
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.
code changes LGTM, thanks!
We'll have to update the example in https://github.com/docker/cli/blob/master/docs/reference/commandline/cli.md#configuration-files
(unfortunately it's already unwieldy, definitely a candidate for a rewrite, but that's another topic)
Thanks. I added a few words to that doc |
thanks @ijc ping @silvin-lubecki still LGTY? |
This is a bit manual (as the unit test attests) so we may find we want to add some helpers/accessors, but this is enough to let plugins use it and to preserve the information through round-trips. Signed-off-by: Ian Campbell <ijc@docker.com>
Make it a simple `map[string]string` for now. Added a unit test for it. Signed-off-by: Ian Campbell <ijc@docker.com>
Signed-off-by: Ian Campbell <ijc@docker.com>
Rebased to resolve the conflict with #1654's edits to |
This is a bit manual (as the unit test attests) so we may find we want to add
some helpers/accessors, but this is enough to let plugins use it and to
preserve the information through round-trips.
Signed-off-by: Ian Campbell ijc@docker.com
- What I did
Added a map to the
config.json
top-level which can be used by plugins.- How I did it
Added a map of string → json.RawMessage. Using RawMessage allows plugins to late bind on the structure without patching
docker/cli
.- How to verify it
I added a unit test, but you could also port your plugin you use it ;-)
- Description for the changelog
N/A -- covered by #1564's entry.
- A picture of a cute animal (not mandatory but encouraged)