Developer Console AEMaaCS - OSGi Configuration - Runtime Environment Variables Display

[#1]

Request for Feature Enhancement (RFE) Summary:	Developer Console in AEMaaCS should display runtime environment variables values too - This helps to know which is the current value being picked (default or custom)
Use-case:	Currently the config.json displayed in the pod at cloud manager for an instance displays configuration for environment variable as is in the codebase -  "configKey": "/configValue/$[env:CUSTOM_KEY;default=9876543210]/rohan", If the CUSTOM_KEY is configured in environment variable then the value that should be displayed is the actual one and not the above one. If it's not configured then the default value should be displayed to give a better idea of whether an environment value is configured for an instance or not.
Current/Experienced Behavior:	User has to navigate to the Environment Variable console to manually verify whether CUSTOM_KEY is configured or not. In a project with 150+ env variables this becomes an unnecessary lookup.
Improved/Expected Behavior:	The config should display the proper correct value. If no environment value is configured then display the default one else display the custom one.
Environment Details (AEM version/service pack, any other specifics if applicable):	2024.10.18311.20241017T104455Z
Customer-name/Organization name:	EPAM Systems
Screenshot (if applicable):
Code package (if applicable):

[#2]

I think it can be easily done by developer. Just open Developer Console with OSGi configs and Environments variables for certain env. and compare.

What will be the benefit of it if we can check that by ourselves?

[#3]

Hi @Rohan_Garg 

I believe there a couple of reasons why is working like this. Adobe might have had additional reasoning, but my guessing is that it has to do with the following:

- Separation of concerns when we talk about roles. Imagine that Cloud Manager is designed to be used by multiple people: developers, testers, product owner and so on. Some technical, some non-technical. So keeping things separate (technical configs vs operations) is desirable.

- What is considered configuration is what you push through your code as service configs for different envs. So a line like "configKey": "/configValue/$[env:CUSTOM_KEY;default=9876543210]/rohan" is a configuration. Your config is then using an env variable named CUSTOM_KEY. When you go to Developer Console -> Status -> Configurations what you should see is exactly what it says: configurations, not the evaluation of your configurations. That is why I believe is a good thing you can actually check that your config is what you expect. And then you have the other tool where you can can the values for you env vars. Imagine that tomorrow someone changes the config in your basecode and instead of CUSTOM_KEY he will use a new env var named CUSTOM_PROP and nothing works after that. How could you know if you config was actually deployed and exists now among the configs on cloud ?

But I do get your point, from a developer perspective that wants to easily troubleshoot and verify stuff. I do feel the same.

I see that Adobe has this new Beta Console ( believe is called skyline-console), this look nicer. Here your idea might fit better. It might displat a reference link or something, that would allow you to navigate from your config to your env var definitions and check the values:

[#4]

@konstantyn_diachenko - Its just a matter of convenience - I have more than 150 environment variables and not sure if RDE, DEV, Stage and Prod have the variables configured. It is of course doable to just manually verify but it won't be the worst thing to skip the manual verification and just show the runtime configuration directly.

[#5]

@Rohan_Garg , yeah, I got your point. We have also a lot of env variables and  that's why I suggested another improvement for console: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-ideas/add-optional-descrip... 

[#6]

@Rohan_Garg 

Thanks for proposing this idea.

This has been reported to the engineering under the internal reference SITES-27066. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to Jira's status.