Environment config depends on agent.config

[pg-yang]

Environment config is based on agent.config file, such as following item in agent.config:

plugin.cpupolicy.sample_cpu_usage_percent_limit=${SW_SAMPLE_CPU_USAGE_PERCENT_LIMIT:-1}

If I remove this item, neither the Environment variable SW_SAMPLE_CPU_USAGE_PERCENT_LIMIT couldn't work

[wu-sheng]

Yes, it relies on that. There is no other place to declare the system env variable name. What are you proposing?

[wu-sheng]

Meanwhile, properties are process level exclusive. It's same to hard coded with a skywalking prefix.
This is the design logic from beginning.

[pg-yang]

We also could organize these words as ENV key, such as SW_PLUGIN_HTTPCLIENT_COLLECT_HTTP_PARAMS(SW as fixed prefix)

How about we provide a config to specify the prefix? the config should be properties(process) level.
Anyway, the conflict of ENV name couldn't be avoided, but modifying a prefix is easier than modifying items in agent.config one by one.
What do you think?

[wu-sheng]

What do you propose? Do you want to put the system environment names in codes? Like using an annotation.

[pg-yang]

I want to make ENV configuration independent.
To meet this purpose, generate the ENV config key through the rule that is similar to the rule of generating the property key.
It would not introduce any annotation.

[wu-sheng]

OK, you would face two things

1. This is a breaking change, we need to generate a list of those environment variables in names with types. It would be very hard to track this. I know the properties don't have this list, but they are listed agent.config already.
2. All existing deployments could be broken without any warning. This is what I am concerned about.

Overall, this feature is fine, but the risk seems too high for a stable agent ecosystem. I can't tell how many agent deployments out there, and which system environments are being used.