Murano client doesn't do retry in case of token expiration

[Viktoria Efimova]

Murano client doesn't do retry in case of token expiration as nova does https://github.com/openstack/python-novaclient/blob/f1ea28349bb8e3a79457137e4d06bb599b30b6c6/novaclient/client.py#L419-L438

Please, add this functionality somewhere at https://github.com/openstack/python-muranoclient/blob/master/muranoclient/common/http.py#L168-L184?

[Serg Melikyan (smelikyan)]

moved back to confirmed since there no activity for several months

[Stan Lagun (slagun)]

no activity for long time

[Jacek Tomasiak (skazi)]

Could you please describe scenario you have in mind?

If I understand correctly, currently murano-client has following options:
1. get username and password from the caller -> authenticate every request with those (i.e. no token caching)
2. get auth token from the caller -> use token to authenticate all requests (fails if token is expired)
3. get both username/password and token from caller -> works like #2, fails for expired token even though we have correct username and password

Correct me if I'm wrong but for me the only one that currently fits this bug is #3 where we actually want fallback to username/password in case of expired token.

If we want to match what novaclient is doing, we would need to change #1 to cache the token from username/password auth (which will create the problem of expiring tokens) and then add re-authentication on top of this.

[Viktoria Efimova (vefimova)]

Yeap, Rally initializes clients with pre-created token and user/password, so this is case #3 that you described. The thing is that if iteration lasts more than 60 mins (what is common case for tests of concurrent deployment of windows ActiveDirectory) then iteration will fail. Also such issue can be faced to if you're trying to deploy such application thru horizon and it takes more than 60 mins.

I suppose, that we don't have to cache token in case of #1. Instead, we need in case of #3 (like in nova client):
- to check before every new request that token is still valid
 and
- to have at least one retry in case of request was sent on last second (59.9) and token expiration happend in murano service during request processing.

[Viktoria Efimova (vefimova)]

Forgot to add: in case of we check token and it apeared to be not valid anymore we need to request a new one.

[Jacek Tomasiak (skazi)]

Just to make sure I get everything right.

We focus on #3. We got user/password and token from caller. At some point during execution we get "token expired" error. Should we start using username/password for each request from that point or request a new token from keystone (using user/password), replace the old one retry current request and continue operation as before (i.e. using token for requests and not using username/password).

[Viktoria Efimova (vefimova)]

Yes, focus on #3, if we sent request and got error then in exception handler we need to re-authenticate (using user/password) and save new token for consequent requests, after that re-sent failed request with this token.

[Jacek Tomasiak (skazi)]

Last question (hopefully): are you using murano client from python code or via shell?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/281697

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/281697
Committed: https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=188b81704eed11fad1eb50843da58c2b027e49f0
Submitter: Jenkins
Branch: master

commit 188b81704eed11fad1eb50843da58c2b027e49f0
Author: Jacek Tomasiak <email address hidden>
Date: Mon Feb 29 20:27:22 2016 +0100

    Add reauth if token is expired and username/password are available

    If client is started with both auth token and username/password, token
    gets higher priority and username/password are not used even if token
    is invalid/expired.

    This change switches muranoclient to DefaultCLI auth plugin which
    removes some redundant code from murano and enables joint handling of
    token and username/password with fallback option in case of expired or
    invalid token.

    This change applies only to Session mode and not legacy HTTPClient.

    In addition the change contains local fix for keystoneclient bug #1551392
    to avoid dependency on change Ic0fcde67fb2e6e2e5ff7506eab3fd29e25fc76e8.

    Change-Id: I9ee326febb9bbdcf7279a35a696ecc58293d70f7
    Closes-Bug: #1499329
    Related-Bug: #1551392

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/291606

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/291606
Committed: https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=299bf4747676329b1f3b8841aaec4ff01d3f19d7
Submitter: Jenkins
Branch: stable/mitaka

commit 299bf4747676329b1f3b8841aaec4ff01d3f19d7
Author: Jacek Tomasiak <email address hidden>
Date: Mon Feb 29 20:27:22 2016 +0100

    Add reauth if token is expired and username/password are available

    If client is started with both auth token and username/password, token
    gets higher priority and username/password are not used even if token
    is invalid/expired.

    This change switches muranoclient to DefaultCLI auth plugin which
    removes some redundant code from murano and enables joint handling of
    token and username/password with fallback option in case of expired or
    invalid token.

    This change applies only to Session mode and not legacy HTTPClient.

    In addition the change contains local fix for keystoneclient bug #1551392
    to avoid dependency on change Ic0fcde67fb2e6e2e5ff7506eab3fd29e25fc76e8.

    Change-Id: I9ee326febb9bbdcf7279a35a696ecc58293d70f7
    Closes-Bug: #1499329
    Related-Bug: #1551392
    (cherry picked from commit 188b81704eed11fad1eb50843da58c2b027e49f0)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/python-muranoclient 0.9.0 release.