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
Is your feature improvement request related to a problem? Please describe.
Finding the allowed values for the tedge config setting for service.timestamp_format is more difficult than it should be.
When trying to change the value, the error response should be more helpful and should show which values are valid (as the names of the values are generally intuitive enough to guide the user to the correct value). Below shows the output when setting an invalid value.
# tedge config set service.timestamp_format iso8601
Error: failed to set the configuration key: 'service.timestamp_format' with value: iso8601.
Caused by:
0: Failed to parse input
1: Matching variant not found
The above output is not very helpful to inform the user which are the valid values, so the only way for the user to check the values is to use the tedge config list --doc command, but then they have to filter the large list using grep (and printed the ~4 lines after the match) as the list command does not support filtering.
tedge config list --doc | grep service.timestamp_format -A 4
Describe the solution you'd like
When setting the service.timestamp_format configuration, if an invalid value is provided by the user, then the error message should also include the allowed values.
For example, the following manually adjusted cli output would be enough (see the last line, Accepted values: ['rfc-3339','unix']).
# tedge config set service.timestamp_format iso8601
Error: failed to set the configuration key: 'service.timestamp_format' with value: iso8601.
Caused by:
0: Failed to parse input
1: Matching variant not found. Accepted values: ['rfc-3339','unix']
Describe alternatives you've considered
Alternatively, we could also support the --doc flag on the tedge config set/get commands, where the user can check the docs for the given property rather than all of the configuration values.
tedge config set service.timestamp_format --doc
service.timestamp_format The format that will be used forthe timestamp when generating service "up" messagesin thin-edge JSON.
Examples: rfc-3339, unix
Additional context
The text was updated successfully, but these errors were encountered:
reubenmiller
changed the title
displace valid variants in error message when setting an invalid value via tedge config set
display valid variants in error message when setting an invalid value via tedge config set
May 3, 2024
Is your feature improvement request related to a problem? Please describe.
Finding the allowed values for the
tedge config
setting forservice.timestamp_format
is more difficult than it should be.When trying to change the value, the error response should be more helpful and should show which values are valid (as the names of the values are generally intuitive enough to guide the user to the correct value). Below shows the output when setting an invalid value.
The above output is not very helpful to inform the user which are the valid values, so the only way for the user to check the values is to use the
tedge config list --doc
command, but then they have to filter the large list using grep (and printed the ~4 lines after the match) as thelist
command does not support filtering.tedge config list --doc | grep service.timestamp_format -A 4
Describe the solution you'd like
When setting the
service.timestamp_format
configuration, if an invalid value is provided by the user, then the error message should also include the allowed values.For example, the following manually adjusted cli output would be enough (see the last line,
Accepted values: ['rfc-3339','unix']
).Describe alternatives you've considered
Alternatively, we could also support the
--doc
flag on thetedge config set/get
commands, where the user can check the docs for the given property rather than all of the configuration values.tedge config set service.timestamp_format --doc
Additional context
The text was updated successfully, but these errors were encountered: