'zhmc partition console' asks for password again although session already created

[andy-maier]

Copied from zhmcclient/python-zhmcclient#308 (opened by leopoldjuergen):

Actual behavior

$ zhmc cpc list
+----------+------------------+
| name | status |
|----------+------------------|
| P000S67B | service-required |
+----------+------------------+
$ zhmc partition console P000S67B UbuntuDemo2
Enter password (for user pedebug at HMC 9.152.151.49):

Expected behavior

No password request

Execution environment

• zhmcclient version: zhmc, version 0.13.1.dev40
• Operating system (type+version): Ubuntu 14.04
• HMC version: 2.13.1
• CPC version:

[andy-maier]

I was able to verify this behavior (cpc list works without prompting for password, partition console asks for password) with zhmc v0.13.1.dev50 (branch andy/fix-find-partition) on RHEL 7.3, with ZHMC_HOST, ZHMC_USERID and ZHMC_SESSION env vars set.

[andy-maier]

I investigated this and found that there is a reason for the password prompt:

The code establishes a notification listener for the OS message notifications. In order to do that, a password is needed for logging on to the Stomp connection (see NotificationReceiver.__init__()). Because the zhmc command was used with a session stored in the environment, a password was not available and needed to be prompted for.

If the zhmc partition console command is executed with the -p option instead of relying on the ZHMC_SESSION env var, that password is used and no password prompt occurs.

I believe it is not possible to use a saved session ID with Stomp, but it deserves further investigation to be sure.

[andy-maier]

Reading the HMC API book 2.13.1 reveals this (CHapter 4, section "Connecting to the API message broker"):

In order to connect to the integrated message broker, clients must provide a valid HMC user name and
password in order to identify the HMC user making the connection. This information is validated using
the standard HMC user authentication mechanisms before allowing the connection to succeed. The
integrated message broker does not allow any anonymous or unauthenticated connections.

It does not mention session IDs, so I'm pretty sure it does not support them there.