Skip to content
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

feat: add default values of entities to inputs.conf #1530

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from

Conversation

hetangmodi-crest
Copy link
Contributor

@hetangmodi-crest hetangmodi-crest commented Jan 16, 2025

Issue number:
ADDON-13362

PR Type

What kind of change does this PR introduce?

  • Feature
  • Bug Fix
  • Refactoring (no functional or API changes)
  • Documentation Update
  • Maintenance (dependency updates, CI, etc.)

Summary

Default values of an entity have been added to inputs.conf to highlight the default configurations for an input.

Changes

In accordance with the add-on convention, an inputs.conf file should specify the default values for an input so that the default values are always present. Therefore, this code change adds default entity values to inputs.conf as defined in globalConfig.

User experience

User will now be able to point out the default values of their inputs in inputs.conf itself. If an add-on user configuring add-on from .conf files only, forgets to provide the default values, these changes would now come from default/inputs.conf and they don't have to wait for error to surface or the add-on to throw out an error.
There would be no change in UX for users using an add-on from GUI or REST endpoints.

Checklist

If an item doesn't apply to your changes, leave it unchecked.

@hetangmodi-crest hetangmodi-crest added the enhancement New feature or request label Jan 16, 2025
@hetangmodi-crest hetangmodi-crest self-assigned this Jan 16, 2025
@hetangmodi-crest hetangmodi-crest requested a review from a team as a code owner January 16, 2025 07:26
@artemrys
Copy link
Member

Is there an impact in the UI or in the behavior of modular inputs if we have this feature?

@sgoral-splunk
Copy link
Contributor

sgoral-splunk commented Jan 21, 2025

Is there an impact in the UI or in the behavior of modular inputs if we have this feature?

@artemrys @hetangmodi-crest I think that the difference in comparision to the current behaviour will be that when a field is not required, but has a default value in inputs.conf and the user saves input without this field, splunk will automatically save the default value instead of an empty one.

@artemrys
Copy link
Member

Is there an impact in the UI or in the behavior of modular inputs if we have this feature?

@artemrys @hetangmodi-crest I think that the difference in comparision to the current behaviour will be that when a field is not required, but has a default value in inputs.conf and the user saves input without this field, splunk will automatically save the default value instead of an empty one.

It makes sense to me, should we add test describing this behaviour?

I think should also be reflected in the "User experience" section.

@artemrys
Copy link
Member

Is there an impact in the UI or in the behavior of modular inputs if we have this feature?

@artemrys @hetangmodi-crest I think that the difference in comparision to the current behaviour will be that when a field is not required, but has a default value in inputs.conf and the user saves input without this field, splunk will automatically save the default value instead of an empty one.

It makes sense to me, should we add test describing this behaviour?

I think should also be reflected in the "User experience" section.

Can this change affect existing or new add-on users somehow? Some unexpected side effect they might experience?

@hetangmodi-crest
Copy link
Contributor Author

Is there an impact in the UI or in the behavior of modular inputs if we have this feature?

No, there is no impact on UI or modular inputs. These default values come from globalConfig itself. Hence, the only delta of an add-on would be - if the add-on's user configures the add-on from .conf files and forgets to not mention the optional values, they would be fetched from default/inputs.conf. For users configuring an add-on from UI or REST endpoints, before or after this change, it won't change their UX at all, as these default values are already present in REST handler scripts.

@hetangmodi-crest
Copy link
Contributor Author

I think should also be reflected in the "User experience" section.

I have updated the description to capture the details from add-on developer and an add-on user's perspective.

artemrys
artemrys previously approved these changes Jan 23, 2025
@hetangmodi-crest hetangmodi-crest requested review from kkedziak-splunk and removed request for kgwizdz-splunk January 30, 2025 06:48
sgoral-splunk
sgoral-splunk previously approved these changes Feb 3, 2025
kkedziak-splunk
kkedziak-splunk previously approved these changes Feb 3, 2025
if type(entity["defaultValue"]) is bool:
self.default_value_info[service["name"]].update(
{
f"{entity['field']}": f"{str(entity['defaultValue']).lower()}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a NIT: f-strings can be omitted here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing out, made the changes.

@@ -4,4 +4,11 @@ python.version = python3
{% if disabled and service_name == input_name%}
disabled = true
{% endif %}
{% for key, values in default_values.items() %}
{% if key == input_name %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need this double for and if. This would be enough:

{% for item, value in default_values[input_name].items() %}
{{item}} = {{value}}
{% endfor %}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made the changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request size/M
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants