Add proxy env vars to pods

[jmontleon]

This configure proxy env vars if they are set on the operator or in the MigrationController CR.

It does not yet address the issue of certificates.

For each of the following check the box when you have verified either:

• the changes have been made for each applicable version
• no changes are required for the item

Affected versions:

• Latest
• 1.1
• 1.0

The CSV is responsible in OLM installs for

• Operator permissions
• Operator deployment
• Operand permissions
• CRDs

The operator.yml is responsible in non-OLM installs for

• Operator permissions
• Operator deployment

The ansible role is responsible in non-OLM installs for:

• Operand permissions
• CRDs

The ansible role is always responsible for:

• Operand deployment

If this PR updates a release or replaces channel

• I created a new z release directory in deploy/olm-catalog/konveyor-operator
• I updated channels in the konveyor-operator.package.yaml
• I created a new release directory in deploy/non-olm
• I created or updated the major.minor link in deploy/non-olm
• Updated the .github/pull_request_template.md Affected versions list

[eriknelson]

LGTM as far as I understand the problem. I'm unsure if the UI server will need to use this or not, @jmontleon do we want to continue testing this before merging or merge this and continue to update as we find problems? This PR is pretty harmless.

[jmontleon]

Yes. I'd like to do some research and take a stab at implementing some approach for getting a CA Bundle in the containers as well. Might have it today depending how other things go and what I find and come up with.

[jmontleon]

If this proves beneficial without the CA work for a customer we can always merge it and come back to CA support later too.

[eriknelson]

If this proves beneficial without the CA work for a customer we can always merge it and come back to CA support later too.

Agreed, the custom proxy CA is potentially an edge case and the env vars alone could be useful to have as incremental support.

[eriknelson]

Tested this in conjunction with a bunch of other patched images we identified that needed changes for the limited support (ignoring the custom proxy CA), and I had success staging and migrating an S2I application from a 3.x -> 4.x disconnected environment requiring a proxy for outside comms in the QE repro environment. I added some background info describing the problems with the other components on the controller PR.

This is definitely useful enough in its current form for us to merge and shoot to release initial support for 1.1.2. The known improvements I'd like to follow up with are:

• I need to add another PR with some docs that describe the overall setup, main concern is 3.x since it requires manual config. I'm not sure that the operator itself needs the proxy vars in its deployment, or if we just need to add the proxy settings to the CR for the operands, @jmontleon want to catch up with you about that.
• The custom proxy CA case we've talked about. Also need to talk to Shawn about that one to get a better idea about what we need to cover.

Needs to be merged in conjunction with:
migtools/mig-controller#473 - Controller support
vmware-tanzu/velero-plugin-for-aws#37 - This code should also be complete. Need to coordinate with @dymurray on this one to figure out how to make sure this gets upstreamed, and if we want to rebase on top of the upstream plugin, or if we want to commit this directly to our fork so we can release this with 1.1.2 in the immediate term and then rebase on the upstream plugin for 1.2.