feat: generate another .conf-file when conf parameter is used #1608
Conversation
|
Should we create |
|
@hetangmodi-crest |
|
I mean the actual parameters with their description and default values (if provided). Just like we are having |
@kkedziak-splunk you can check one of our TAs to see the example, one of the cloud TAs should be a good candidiate. |
...addons/expected_output_global_config_everything/Splunk_TA_UCCExample/README/inputs.conf.spec
Outdated
Show resolved
Hide resolved
| @@ -80,7 +80,7 @@ def _set_attributes(self, **kwargs: Any) -> None: | |||
| value = str(field_default_value) | |||
|
|
|||
| default_values[entity["field"]] = value | |||
| field_value_parts.append(f"Default: {field_default_value}") | |||
| field_value_parts.append(f"(Default: {value})") | |||
There was a problem hiding this comment.
Can you please shed more light on this change?
There was a problem hiding this comment.
This looks like a lot of changes but this is similar to what was before, but slightly rewritten and with very small changes. For example, I changed the variables, as some names meant something else, plus I changed one if to remove one level of indentation.
The flow:
If global config is not specified, return (the same as above, but I negated the "if" to remove the indentation)
For every service:
- Setting
spec_properties. If we don't have a "conf" parameter, the structure that stores spec properties forinputs.confis used. Otherwise, we get a structure for a separate config (this is a change, as previously we only saved everything ininputs.conf, evenconfservices). - Handling
disableNewInput- not changed. - Previously we did not iterate the entities if there was the "conf" parameter - this is removed now
- For every entity in the service:
4.1. Skip if field name == "name" (not changed)
4.2. Skip if field type == "helpLink" (added - inspired by openapi.json)
4.3. Handling thedefaultValue. This already happened but I moved it up, because there were situations (not tested), where if we had a bool value, the inputs.conf had e.g.field = true, while inputs.conf.spec hadDefault: True(first letter was upper case). I also added a test for this branch.
4.4. The spec line is generated as follows:{field_name} = {field_help} (default: {default_value})- small change to what was before, can be seen in tests.
There was a problem hiding this comment.
This explanation as code comments would help much more than on the PR.
# Conflicts: # splunk_add_on_ucc_framework/generators/conf_files/create_inputs_conf.py
# Conflicts: # splunk_add_on_ucc_framework/generators/conf_files/create_inputs_conf.py
|
@hetangmodi-crest would appreciate your review on this change please :) |
There was a problem hiding this comment.
Shouldn't we also add the custom .conf.spec file in this expected folder? In our example, I think it would splunk_ta_uccexample_service_with_conf_param.conf.spec, as the actual content where the inputs would be written is splunk_ta_uccexample_service_with_conf_param.conf. The name would be the same as the one stored REST handler scripts.
splunk_add_on_ucc_framework/generators/conf_files/create_inputs_conf.py
Outdated
Show resolved
Hide resolved
| @@ -80,7 +80,7 @@ def _set_attributes(self, **kwargs: Any) -> None: | |||
| value = str(field_default_value) | |||
|
|
|||
| default_values[entity["field"]] = value | |||
| field_value_parts.append(f"Default: {field_default_value}") | |||
| field_value_parts.append(f"(Default: {value})") | |||
There was a problem hiding this comment.
This explanation as code comments would help much more than on the PR.
artemrys
changed the title
There was a problem hiding this comment.
For me to understand - we do not have service_with_conf_param in inputs.conf anymore but we did not create a dedicated file for it during the build time.
Did we check that this file will be indeed created when a new input is created?
Can we please also check whether AWS add-on is not impacted because of this change.
There was a problem hiding this comment.
- I was experimenting and decided to revert this part and add entries to
inputs.conffor every input, as this parameterpython.version = python3, although not read by the input, it may be read by Splunk when starting the input. - Yes, the file is created when input is added. I tested it locally.
- AWS shows no changes (used
diff -r dir1 dir2) but it is because it contains those files in thedefaultdirectory. The same is with the GCP TA.
One more thing about conf files not being created - I was experimenting with that and it seems that we could create those files with default values. But on the other hand we haven't done that so far. And I saw that default values are handled by the handlers.
# Conflicts: # splunk_add_on_ucc_framework/generators/conf_files/create_inputs_conf.py # tests/unit/generators/conf_files/test_create_inputs_conf.py
Code Coverage 🎉
|
Issue number: ADDON-78536
PR Type
What kind of change does this PR introduce?
Summary
Changes
The "conf" parameter for inputs indicates that a separate config file should be used. Therefore inputs with this parameter should not be included in inputs.conf and inputs.conf.spec.
Also,
disableNewInputsparameter is improved.User experience
No changes.
Checklist
If an item doesn't apply to your changes, leave it unchecked.