Comment 1 for bug 1648677

A bit more info, I have just tried this out and I see that as mentioned, the real password does not change but its record in the keystone database does. This in turn triggers a revocation_event that causes all active tokens for that service user to be revoked. I can only assume that when the password update call is made, keystone and/or mysql is using extra information such as timestamp when encoding the password string and this results in a new record in the database each time the call is made even if the password itself has not changed.