Harmonize env variable naming for those which are not bound to a particular service

[mmattel]

Based on a discussion with ocis devs:

Given the situation that we have:

• services with env variables and a yaml file
• some env variables are not bound to a service and have a global role
• global env's can be overwritten by the corresponding service env
• the beginning of a service env variable starts with the service name for clear identification
• the naming of global env variables is inconsistent,
  some start with OCIS_ and others with LDAP_ (more to be identified)
• service env's and yaml get documented automatically,
  global ones are in state undocumented and/or unknown

we run into issues that need to be resolved asap:

1. global env's need an harmonized namespace and must start with OCIS_
   means like LDAP_CACERT --> OCIS_LDAP_CACERT
2. global env's / yaml need to be exported to a file automatically like we do it with services so we can import it into the documentation. Proposal for a filename: common or global. Treat it like a service knowing it is none.
3. existing old env's that get renamed may continue to co-exist for a short period of time with a deprecation note to have a smooth transition

Impact when fixed:

• devs and admins know what we have and where it is / belongs to
• harmonized and automated processes for documenting stuff
• visibility: global envs dont get lost interms of documentation and use
• future proof

Please add your points if things are missing.

This would also help when addressing #3456 (Command line option to list active config parameters)

@wkloucek @dragonchaser @micbar @butonic

[micbar]

1. OCIS_ and LDAP_ are our two global namespaces. AFAICT these are the only ones.
2. I think we currently have no shared variables inside of the yaml files. The shared values are only ENV variables, @wkloucek correct?

[wkloucek]

Logging, tracing and some secrets are already shared config in the config files.

There is also a shared STORAGE_TRANSFER_SECRET

[wkloucek]

We also have STORAGE_GATEWAY_GRPC_ADDR and STORAGE_GRPC_ADDR, which are unique to the settings service. See also #4058

[michl19]

@pmaier1 please comment as there is a PM decision needed

[pmaier1]

While important, this is not in scope of GA. We'll put it on the roadmap afterwards.

[mmattel]

Referencing #4133 (fix OCIS_RUN_SERVICES)
This is a good example where an env gets "lost" as it has a global scope, popping up nowhere, if not covered by a automated collecting process embedded in the automated documentation process.

Changes found by chance... 🤦‍♂️

[mmattel]

One more reference: #4235 which uses OCIS_ADMIN_USER_ID. This env is curently used in IDM and SETTINGS but we are lacking a description about the env itself and the impact. Note the text in the PR saying: In the .ldif file in this example, the admin user id is base64 encoded. You need to decode it to make it work. Such info is necessary as part of the description of OCIS_ADMIN_USER_ID.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[mmattel]

bump

[wkloucek]

We also have MICRO_REGISTRY

[wkloucek]

I created an example how to get MICRO_REGISTRY in the config documentation generation process: #4910

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[mmattel]

do not close

[mmattel]

MICRO_REGISTRY and similar stuff is now semi-automatic documented as enhanced envvars in the admin docs in Special Scope Envvars.

[mmattel]

Closing as implemented via referenced PR's