cli/config: add GetFeature, SetFeature for ConfigFile

[laurazard]

- What I did

Add exported functions to get/set values from ConfigFile.Features map introduced in c5016c6.

- How I did it

Carefully.

- How to verify it

go test -v -count=1 -run=Test.etFeature ./cli/config/...

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[thaJeztah]

Will we need any synchronisation around these?

Also the Features being both exported and having accessors starts to feel "wrong" (admitted, we already have a similar situation for the Plugins field above).

[laurazard]

Oh! I forgot to hit the submit button before I got up for lunch 🙃 I was about to post a comment asking about whether this made sense or not — I came across the Plugins one while working downstream.

Synchronization would benefit us here, although it's useless unless we implement an actual file lock to prevent concurrent access by different processes, which I think is a bigger concern.

[thaJeztah]

Yeah, this is gonna be more of a problem if more plugins start to manipulate these out of band; more so if it's stored in memory, and now possibly memory state no longer reflecting actual state of the file, think;

• cli loads config in memory
• calls plugin -> which may manipulate the config
• now cli's config in memory is out of sync
• but cli could write to disk (reverting the changes made by the plugin)

I haven't checked the code locally, but if *ConfigFile here is the struct that includes the json: labels, then I'm guessing these fields were exported because of that (i.e. (un)marshaling requires them to be exported), so probably we can't change that immediately, unless we define separate structs/types (separate types for (un)marshaling than for "in-memory" state; the latter would have un-exported fields and accessors).

[laurazard]

Hmm, I mostly agree. I think ultimately this is something that will only be "properly" solved by a) having the plugins not change the config directly, but communicate changes over the socket to the CLI and have the CLI process make those changes, and b) implementing a file lock so other processes don't touch the config at the same time.

However, for right now, barring concurrent process access, I think this:

cli loads config in memory
calls plugin -> which may manipulate the config
now cli's config in memory is out of sync
but cli could write to disk (reverting the changes made by the plugin)

Isn't a huge problem since we can know when we're writing the file to disk from the CLI process and can try to make sure we don't do it while the CLI is calling a plugin.

[laurazard]

I can shelve this PR until we have file locking in place, or we can keep it (even in a somewhat incomplete state) to add synchronization, although I don't think that will bring us as much value right now.

[krissetto]

nit: if we go for these get/set helpers, i'd probably split out the Delete/RemoveFeature() func as well to both separate the functionality, and also because "setting an empty string" does not really make me think of "removing a key/value pair from a map" (maybe the empty string is a value someone legitimately wants)

[laurazard]

I agree in principle, the reason why I did it that way was for consistency/since it might be confusing to have the features setters work differently than the plugin's –https://github.com/laurazard/cli/blob/b463a15f78e8c74c7f956ab5511d3c3ea60b1d57/cli/config/configfile/file.go#L345-L349

I'm happy to change this though.

[krissetto]

Oh, I didn't even notice that! No hard feelings here anyway

[Benehiko]

I would be fine with getting this merged and then tracking a new issue solving config file synchronization.

Right now (I think 😅) we don't have an issue with config updates from the plugins and will only be a problem in the future - under certain circumstances.