You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The plugin should provide these TLS parameters. However, I don't have a good idea now to support a lot of parameters. Generally, I think one of the following forms should be okay.
WITH
root_ca = val,
client_ca = val,
...;
WITH
tls = {
"root_ca": val,
"client_ca": val,
...
};
I want to know/discuss if there's a good way to set all parameters at once.
Note
SensorBee's data package should provide an easy way to process parameters passed as data.Map. Ideally, it should also support something like (JSON) schema.
I also thought about one of these variants. Will the second one be parsed correctly without quoting the whole value? If not, it will force double quote escaping inside double quotes.
I also thought we could specify some external file with the desired settings or use some section in the main yaml file. The latter as a feature available to any plugin or as a simple function could be a cool feature of the whole product.
Will the second one be parsed correctly without quoting the whole value?
Yes, WITH parameters accepts map values.
I also think using an external file is a good option because a certificate needs to be read from a file anyway in most cases. A user has to be careful of the working directory of the process, though.
The latter as a feature available to any plugin or as a simple function could be a cool feature of the whole product.
This is very interesting. At the moment, I think the definition of a component like a source and its configuration should be managed in one place (i.e. in BQL). However, I'll keep thinking of applying this approach to our existing use cases to see how suitable it is.
To parse params data.Map in plugins, we're thinking about supporting this functionality in data package of SensorBee sensorbee/sensorbee#121 . Defining many parameters in a plugin could become easier with it.
Activity
Albibek commentedon Oct 20, 2016
I also thought about one of these variants. Will the second one be parsed correctly without quoting the whole value? If not, it will force double quote escaping inside double quotes.
I also thought we could specify some external file with the desired settings or use some section in the main yaml file. The latter as a feature available to any plugin or as a simple function could be a cool feature of the whole product.
nobu-k commentedon Oct 20, 2016
Yes,
WITHparameters accepts map values.I also think using an external file is a good option because a certificate needs to be read from a file anyway in most cases. A user has to be careful of the working directory of the process, though.
Parsing YAML and converting it into
data.Mapis quite simple: https://github.com/sensorbee/sensorbee/blob/master/cmd/lib/run/cmd.go#L49 . So, supporting bothtls = {map}and something liketls_config_file = "/path/to/config.yml"might be possible.This is very interesting. At the moment, I think the definition of a component like a source and its configuration should be managed in one place (i.e. in BQL). However, I'll keep thinking of applying this approach to our existing use cases to see how suitable it is.
nobu-k commentedon Oct 27, 2016
To parse
params data.Mapin plugins, we're thinking about supporting this functionality indatapackage of SensorBee sensorbee/sensorbee#121 . Defining many parameters in a plugin could become easier with it.