Doc: Environment variables cannot be in config.string comments.

[mashhurs]

Release notes

[rn:skip]

What does this PR do?

Adds a limitation where environment ${VAR}s cannot be used in config.string. To avoid pipeline run config failure, $ can be removed.

Why is it important/What is the impact to the user?

From functional point of view, users are not impacted.

Checklist

• [ ] My code follows the style guidelines of this project
• [ ] I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
• [ ] I have added tests that prove my fix is effective or that my feature works

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Closes Remove comments of config.string. #16625
• Closes Commented out variable substitutions may still be evaluated in pipelines.yml #16008

Use cases

Screenshots

Logs

[mashhurs]

Doc previews:

• https://logstash_bk_16689.docs-preview.app.elstc.co/guide/en/logstash/master/configuration-file-structure.html#comments
• https://logstash_bk_16689.docs-preview.app.elstc.co/guide/en/logstash/master/environment-variables.html

[donoghuc]

Perhaps I am misunderstanding the issue but I thought that the problem here is that interpolation occurs regardless of whether the interpolation site is within a comment or not due to how the template is generated. This can lead to some somewhat confusing behavior where commented out sections still need values for interpolated values. The root of the issue is just the order of operations for interpolation in turning the information from template to instruction. SO instead of saying interpolation is not allowed instead should we describe the behavior and note that if you have interpolations anywhere in the string you need to ensure you have provided values?

[mashhurs]

Perhaps I am misunderstanding the issue but I thought that the problem here is that interpolation occurs regardless of whether the interpolation site is within a comment or not due to how the template is generated. This can lead to some somewhat confusing behavior where commented out sections still need values for interpolated values. The root of the issue is just the order of operations for interpolation in turning the information from template to instruction. SO instead of saying interpolation is not allowed instead should we describe the behavior and note that if you have interpolations anywhere in the string you need to ensure you have provided values?

I wonder what benefits does end user get if we explain the interpolation behavior.
From the end user experience, my practical approach here, user has mostly a running pipeline, later on comments env ${VAR} of the config.string. And once LS starts, the user faces an error and start searching context for using env ${VAR} in comments.