I did mention it was a work in progress right
For now there are a couple ways to do this but they are complete workarounds/hacks. You could use a “config” domain where it doesn’t get replicated. The code promotion happens at another domain. Then load some environmental variables from the config domain with a helper method.
Secondly, which we did for one customer was that the “password” fields in instances themselves where strings but the passwords entered there where encrypted using an external key that was accessible on all appliances. So in a sense, still encrypted but not utilizing the built in encryption of the appliance. The code was written that it would load this “key” to unencrypt the encrypted hash “string” passwords. This process was also not for code import/export promotability but they had their own security reasons why they wanted to have passwords that could be passed from cloudforms to other systems and since they would have the key as well they could also unencrypt these fields being passed. Same concept could apply here.
Either way both still don’t really fix the underlying problem that in the promotion process we are in need to also keeping track of a region “key” to be able to unencrypt these fields and then re-encrypt using the new key for the new region.
The question is, how will it live in git. encrypted from old region or what? but where are you keeping the key. Surely having that key in git is just asking for trouble.
I feel like the “right” answer would mean to add some features to /var/www/miq/vmdb/lib/tasks/evm_automate.rake in the import logic to be able to input a key during the import so it knows how to unencrypt the password fields to the import using the current regions key.