Orchestration runtime configuration file resets with every upgrade

Hello ​@swapnabaylor ,
Could you please provide more details regarding the problem because it’s a bit hard to understand where exactly the issue appears as runtime config is used in different parts of the platform.
Runtime config in DPM - I'd say the best practice is to make a backup of the config before the upgrade so you can always restore it by just copying it back in a second, but i haven’t seen the situation where it would suddenly disappear after the upgrade.
Runtime config in Runtime\Orchestration server - there are various config “fragments” that are stored in git tied to your environment and the latest version of these fragments pushed to the git branch is deployed on the runtime server whenever you restart the runtime server.
Runtime config is also used in your ONE Desktop application and if you switch between different build version after the upgrade you’ll have to export/import runtime config to have everything in place to continue using the app with all the dependencies.

It’s also important to know which version of ONE are we talkin about in this case, what kind of upgrade you performed, and what type of deployment do you have (On-Prem, PaaS, PaaS+).

In general this is probably more of a question for our support team as it’s hard to understand what can possibly be wrong without access to environment and proper investigation.

Thank you!
Ivan
 

Hi Evan,

I wanted to bring to your attention an issue we've been encountering with our workflows on the orchestration server.

To ensure successful execution, we need to add several configurations—such as database connection details (for writing data) and specific URLs required to run the OneDesktop plan—into the runtime configuration file. However, with each upgrade, these settings are being wiped out and reset, which causes our workflows to fail.

Restoring these configurations is a time-consuming process and introduces unnecessary delays. In my opinion, these settings should persist across upgrades to maintain workflow stability and reduce manual intervention.

Would it be possible to explore a solution that preserves these configurations during upgrades?

Hi ​@swapnabaylor ,
Could you please share some additional details like the versions you were upgrading between, the type of deployment (self-managed/on-prem or Ataccama cloud/hybrid)?

Can’t say that i encountered the same problem during the upgrades i participated in but if you share the details i mentioned above i can’t try to check internally if somebody experienced the same problem.
I’m not sure what kind of architecture your environment has but at least in Ataccama Cloud environments usually you would push the latest version of the runtime config to a git branch associated with orchestration server and the latest version of content available in git should be deployed on the server whenever you restart\redeploy the runtime server pod running k8s, this way the configuration should be preserved.

However, as i mentioned earlier, this sounds like something that requires a Support Request and more details to be created to be investigated properly. 

Thank you!
Ivan