Possible conflict between azure-cli package and fence-agents-azure-arm package

This is autogenerated. Please review and update as needed.

Describe the bug

when installing the fence-agents-azure-arm package to configure azure fence agent on RHEL cluster as per the document: https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/high-availability-guide-rhel-pacemaker#cluster-installation and then trying to install the azure cli on the same machine, the azure cli commands is failing , a below is an example “az login”.

the installtion of fence-agents-azure-arm package is installing the python3-azure-sdk package, but I am not sure how this would affect the use of the azure cli. if the python3-azure-sdk package is removed, the azure cli commands works fine.

note : trying the older versions of azure-cli would not help too. would you please help us to understand how they are correlated ? and if there is any solution to have both of them on the same machine ?

Command Name az login

Errors:

The command failed with an unexpected error. Here is the traceback:
__init__() got an unexpected keyword argument 'user_agent'
Traceback (most recent call last):
  File "/lib64/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 658, in execute
    raise ex
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 721, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 692, in _run_job
    result = cmd_copy(params)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 328, in __call__
    return self.handler(*args, **kwargs)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/command_modules/profile/custom.py", line 158, in login
    use_cert_sn_issuer=use_cert_sn_issuer)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 175, in login
    subscriptions = subscription_finder.find_using_specific_tenant(tenant, credential)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 815, in find_using_specific_tenant
    client = self._create_subscription_client(credential)
  File "/lib64/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 839, in _create_subscription_client
    **client_kwargs)
TypeError: __init__() got an unexpected keyword argument 'user_agent'

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information. it can be tested also on centos 8 machines with HA repos enabled, and azure cli repos enabled.

• Put any pre-requisite steps here…
• yum install fence-agents-azure-arm
• yum install azure-cli
• az login --service-principal --allow-no-subscriptions -u {} -p {} -t {}

Expected Behavior

to be able to login successfully

Environment Summary

Linux-4.18.0-269.el8.x86_64-x86_64-with-centos-8, CentOS Stream 8
Python 3.6.8
Installer: RPM

azure-cli 2.31.0

Additional Context

[jiasli]

would you please elaborate more about the solution (as far as I understood, it would be something similar to the workaround) ?

Ah. “We” here means us, Microsoft. If you check our DEB packages, it actually contains its own python. I am not really sure why the same is not done for the RPM package (it was developed by the previous team years ago), but I will definitely work on this in the future.

Actually, you don’t need to activate the venv for az to work. You can simply launch az in the venv:

docker run -it --rm --workdir /root python bash

python -m venv az-env
az-env/bin/pip install azure-cli
az-env/bin/az --version

You may also add az-env/bin/ to PATH so that az is available everywhere:

export PATH="/root/az-env/bin:$PATH"
az --version

[imabedalghafer]

@jiasli Thank you so much for your help on the case. The tests now are working fine with the provided workaround. please feel free to close the issue or if you would like to keep it open for future reference it is up to you 😊