modules/installation-mirror-repository: Drop unnecessary 'export'

[wking]

The export landed with the module in ced98c6 (#16678). But these are local variables that we expand when calling the mirror command. The mirror command receives them from its command line arguments; we don't need export to expose them in the mirror command's environment as well.

/assign @kalexand-rh

[kalexand-rh]

@wking, is this true back to 4.2?

@jiajliu, will you PTAL?

[jiajliu]

If no need export the variables, then we may update the mirror command with the local variables instead of env variables in "Mirror the repository" step too.

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
     --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
     --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
     --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}

hdyt? @wking

[wking]

If no need export the variables, then we may update the mirror command...

The example you have is what we have now in master. How did you want me to change it? Here's an example showing local variables expanded by the shell before they are fed to a subcommand, in case that helps clarify:

$ A=whatever
$ python -c 'import os, sys; print(sys.argv, [k for k in os.environ.keys() if "A" in k])' "${A}"
(['-c', 'whatever'], [..., 'PATH', ...])

The ${A} is expanded to whatever by the shell, but A is not an environment variable in the Python process.

[jiajliu]

I mean, if we want to keep all variables for long-time usage, then better to set env variables permanently(not just export in the shell). And if we update it to use local variables in one-time shell, then we can just use the command with correct variables. Maybe no need to set local variables before it and then call it.
Now:

 OCP_RELEASE=<release_version> 
 LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>' 
 LOCAL_REPOSITORY='<repository_name>' 
 PRODUCT_REPO='openshift-release-dev' 
 LOCAL_SECRET_JSON='<path_to_pull_secret>' 
 RELEASE_NAME="ocp-release" 

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
     --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
     --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
     --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}

I meant:

oc adm -a <path_to_pull_secret> release mirror \
     --from=quay.io/<repository_name>/ocp-release:<release_version> \
     --to=<local_registry_host_name>:<local_registry_host_port>/<repository_name>\
     --to-release-image=<local_registry_host_name>:<local_registry_host_port>/<repository_name>:<release_version> 

Anyway, it's not a big deal for this part, i think users can understand either, so it is ok for me to merge the pr without any changes.

[kalexand-rh]

@jiajliu, @wking, any objections to applying this change back to 4.2?

[wking]

I mean, if we want to keep all variables for long-time usage, then better to set env variables permanently(not just export in the shell).

Folks can do that. But I don't think we want to get into that level of detail in the docs. Folks who are interested in declaring these in their ~/.bashrc or whatever will already understand that they can add an export ... for that sort of thing.

And if we update it to use local variables in one-time shell, then we can just use the command with correct variables.

Isn't that what I'm doing? I think declaring them on separate lines like we've been doing gives space for the <1> and such that would make a single line that plugged in a bunch of placeholders complicated. Also, shell variables are already an established syntax for placeholders. I'd rather use them and not our ad-hoc <...> placeholders. Like:

oc adm -a "${LOCAL_SECRET_JSON}" release mirror \
     --from="quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}" \
     --to="${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}" \
     --to-release-image="${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"

and then a section that walked through:

• ${LOCAL_SECRET_JSON} is a...

etc. But that sort of change seemed like a bigger pivot than I want to argue through, so I'm just focusing on the export ;).

... any objections to applying this change back to 4.2?

I am agnostic about any backporting. "No backporting at all", "backporting through all the versions", and anything in between are all fine with me.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.