blackbox_exporter icon indicating copy to clipboard operation
blackbox_exporter copied to clipboard

config: add json tags to config structs

Open Jakob3xD opened this issue 1 year ago • 11 comments

This adds json tags to config struct fields. This is needed for us to reuse the structs in an internal kubernetes operator.

If just adding the tags is unwanted, I can also look into adding general support for json configs. We would need to add UnmarshalJSON functions like the UnmarshalYAML functions.

Used SED to add the json tags.

sed -i 's/`\(yaml:"\(.*\)"\)`/`\1 json:"\2"`/g' config/config.go

Closes #1308

Jakob3xD avatar Oct 16 '24 09:10 Jakob3xD

If just adding the tags is unwanted, I can also look into adding general support for json configs. We would need to add UnmarshalJSON functions like the UnmarshalYAML functions.

thank you for sending this in, just tags are okay.

I am not sure if we want to add support for json configs, I don't see a big reason to add support for json configs.

electron0zero avatar Oct 16 '24 11:10 electron0zero

thank you for sending this in, just tags are okay.

Perfect, thank you.

Jakob3xD avatar Oct 16 '24 11:10 Jakob3xD

Just adding the json tags won't work as it also needs custom Unmarshal functions. As the json support is not wanted? I might close the PR and do the changes in my fork :/ (Currently still working on the custom Unmarshal functions. Once it is done I would open an PR and you can decide if you want it or not?)

Jakob3xD avatar Oct 17 '24 16:10 Jakob3xD

also needs custom Unmarshal functions

we don't mind having the JSON Unmarshal functions, it would be useful to folks using Blackbox exporter as a library and build on top of Blackbox exporter like you are doing

What I meant was the full fledged support for configuring blackbox exporter via a json config file instead of YAML, in that side, will stick with YAML only.

electron0zero avatar Oct 17 '24 17:10 electron0zero

First step is done with the custom Unmarshal functions. I might need to add some Marshal functions as well. Can already tell that the current json lib is a pain as it does not support inline fields.

If wished I can also generate the json test cases during the test by converting the original yml test case to a json file. Would remove the "duplicate" test data.

Jakob3xD avatar Oct 18 '24 11:10 Jakob3xD

If wished I can also generate the json test cases during the test by converting the original yml test case to a json file. Would remove the "duplicate" test data.

yes, that would be better then the duplicate config files.

electron0zero avatar Oct 18 '24 14:10 electron0zero

As an additional question. Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted. From what I know right now, there is no nice way to Marshal the config. To solve this we could make all the Modules pointers that would get omitted.

Jakob3xD avatar Oct 21 '24 14:10 Jakob3xD

Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted.

I don't think we thought about this before, this might be the default. changing the way config is Marshaled would need a little more discussion.

if you want to change that marshaled, I would recommend creating an issue to discuss this with everyone, and if we agree on changing, i would prefer it to be it's own PR.

electron0zero avatar Nov 27 '24 10:11 electron0zero

@Jakob3xD checking in on this PR, we would be open to merge this if you can update and rebase it.

electron0zero avatar Aug 01 '25 11:08 electron0zero

@Jakob3xD following up on this, I am open to merge this if this can be rebased and updated to include changes from master. 🙏🏼

electron0zero avatar Oct 30 '25 17:10 electron0zero

@electron0zero sorry for the late response. I´ll try to have a look at this in the next week to get this done.

Jakob3xD avatar Nov 03 '25 07:11 Jakob3xD