:warning: ⛔️ Pulp2 is EOL as of November 30 2022, for more info visit this link https://pulpproject.org/2022/09/19/pulp-2-eol/. ⛔️ Functional tests for Pulp 2.
Running in Openstack, the RHEL env would run into an issue where the temp file for the api connection in ~/.ssh/controlmasters was still present when running the cli commands. This would result in a known and harmless stderr output for the curl command with the ControlPath being present.
Failure Output
17:57:18 for stream in (process.stdout, process.stderr):
17:57:18 > self.assertEqual(len(stream), 0, process)
17:57:18 E AssertionError: 323 != 0 : CompletedProcess(args=('curl', '-o', '/tmp/tmp.tkKzJgkl2U/test.gz', '-sH', 'Accept-encoding: gzip', '-k', '-L', 'https://host-10-0-149-170.openstacklocal/pulp/repos/89f7e5af-c2a4-4016-8311-a5efd04fcf26/images/pxeboot/vmlinuz'), returncode=0, stdout='', stderr="mux_client_request_session: session request failed: Session open refused by peer\r\nWarning: Permanently added 'host-10-0-149-170.openstacklocal,10.0.149.170' (ECDSA) to the list of known hosts.\r\nControlSocket /home/jenkins/.ssh/controlmasters/aec53c52cae50a8fdc5ce8dd1984bd47f969083e already exists, disabling multiplexing\r\n")
Research
The common solution cross-referenced from a few sources comes down to the following:
Then exit any existing SSH connections, and make a new connection to a server. Now in a second window, SSH to that same server. The second terminal prompt should appear almost instantaneously, and if you were prompted for a password on the first connection, you won’t be on the second. An issue with connection sharing is that sometimes if the connection is abnormally terminated the ControlPath file doesn’t get deleted. Then when reconnecting OpenSSH spots the previous file, realizes that it isn’t current, so ignores it and makes a non-shared connection instead. A warning message like this is displayed:
ControlSocket /tmp/ssh_mux_dev_22_smylers already exists, disabling multiplexing
rm the ControlPath file will solve this problem.
Either removing the ControlPath dir before using the cli_client could be done
or not monitoring the process.stderr for the curl request.
An Easy Proposed Solution
Removing the process.stderr check, as this is the easiest way to esolve this issue. The context manager for the cli_client will still catch non-zero return codes. Any other information is being caught by process.stdout (which still may be a bad idea). The following gunzip action will verify the content of the encrypted gzip saved by curl.
Problem
Running in Openstack, the RHEL env would run into an issue where the temp file for the api connection in ~/.ssh/controlmasters was still present when running the cli commands. This would result in a known and harmless stderr output for the curl command with the ControlPath being present.
Failure Output
Research
The common solution cross-referenced from a few sources comes down to the following:
Either removing the ControlPath dir before using the cli_client could be done or not monitoring the
process.stderr
for the curl request.An Easy Proposed Solution
Removing the
process.stderr
check, as this is the easiest way to esolve this issue. The context manager for thecli_client
will still catch non-zero return codes. Any other information is being caught byprocess.stdout
(which still may be a bad idea). The followinggunzip
action will verify the content of the encrypted gzip saved by curl.References