ostf(health checks) isn't working with changed default passwords

Bug #1281838 reported by Aleksandr Shaposhnikov
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Released
High
Artem Roma

Bug Description

Health check stops working if horizon/keystone/etc passwords was changed from default.
Fuel should have an options to provide heath checks functionality with new passwords or to workaround this by any other way (I doubt that it's possible).

Steps to reproduce:
1. Install cluster (doesn't matter what version,architecture ad so on)
2. Change default password to Horizon.
3. Try to run health checks.

Expected behavior:
Health checks should be performed as usual.

Observed behavior:
Most of health checks shown as failed.

tags: added: customer-found
Revision history for this message
Mike Scherbakov (mihgen) wrote :

If user changed password in Horizon, then we can't do anything now, that's true. The right way would be, I assume, to extend functionality of OSTF and to provide updated credentials in Health Check tab.

Changed in fuel:
milestone: none → 4.1
milestone: 4.1 → 5.0
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Mike Scherbakov (mihgen) wrote :

I'm setting up Medium priority as OSTF can be used before password is changed by the user via Horizon. Also, OpenStack Settings Tab allows to set Admin password beforehand, and overall the situation when user changes password later via Horizon doesn't seem happening that often.

Revision history for this message
Andrew Woodward (xarses) wrote :

This does happen frequently enough that I've seen support take issues for this and I've discussed this with users on IRC and during customer deployments. I've even created a bug that the openrc file isn't validated https://bugs.launchpad.net/fuel/+bug/1250578.

I think the core problem here is that there is reliance in the cluster between the password stored in nailgundb (for OSFT) the openrc file, and the current passwords for the cluster. We need to test these relationships and all of the OSTF tests fail and imply that the cluster is broken when something as simple as the password changed.

Revision history for this message
Vladimir Kuklin (vkuklin) wrote :

This is related to the cluster lifecycle management. Postponing this issue to the granular deployment for 5.1

Changed in fuel:
milestone: 5.0 → 5.1
summary: - ostf(health checks) isn't working changed default passwords
+ ostf(health checks) isn't working with changed default passwords
Revision history for this message
Mike Scherbakov (mihgen) wrote :

> This is related to the cluster lifecycle management. Postponing this issue to the granular deployment for 5.1
How does it correlate to granular deployment?

Please see my & Andrew's comments above. We need:
1) Provide clear message to the user that authorization failed due to possible change of user/pass in Horizon
2) Provide a user with an ability to enter new tenant/user/pass for running OSTF. It should be clear and easy in terms of user experience - ideally somewhere at the top of OSTF tab.

Changed in fuel:
milestone: 5.1 → 5.0
assignee: nobody → Fuel UI Team (fuel-ui)
Revision history for this message
Evgeniy L (rustyrobot) wrote :

Hi,

We see here several solutions

1) Keep new passwords in OSTF, I don't like this approach because we will send wrong
credentials from nailgun to puppet manifests.

2) Enable user/password field in case of deployed cluster, here user will be able to change password
via UI. And in case of new node deployment we will send right credentials. But in this case user may think
that we can change password which wasn't changed manually in Horizon.

3) Can we create new user especially for OSTF? In this case I think it will be ok to keep/change credentials in OSTF.

Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

as about 3-d solution - we can it create during puppet invocation.

tags: added: ostf
Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

But anyway Naigun should be possible provide data (login/tenant/pwd) for ostf user(If we choose this way)

Changed in fuel:
milestone: 5.0 → 5.1
Changed in fuel:
milestone: 5.1 → 5.0
Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

For 5.0 release we add descriptive message about auth failure

Changed in fuel:
milestone: 5.0 → 5.1
Revision history for this message
Mike Scherbakov (mihgen) wrote :

This bug has hit many users. Increasing priority to High. Let's make a fix finally.

Changed in fuel:
importance: Medium → High
tags: added: ui
Revision history for this message
Alexandra Morozova (astepanchuk) wrote :
Changed in fuel:
assignee: Fuel UI Team (fuel-ui) → Alexandra Morozova (astepanchuk)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-ostf (master)

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

Changed in fuel:
assignee: Alexandra Morozova (astepanchuk) → Artem Roma (aroma-x)
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to fuel-ostf (master)

Reviewed: https://review.openstack.org/102507
Committed: https://git.openstack.org/cgit/stackforge/fuel-ostf/commit/?id=6f514d34870261ca4775ee2d843301965d260303
Submitter: Jenkins
Branch: master

commit 6f514d34870261ca4775ee2d843301965d260303
Author: Artem Roma <email address hidden>
Date: Wed Jun 25 14:52:18 2014 +0300

    OS access credentials processing added

    What is done:
    - os access credentials retriving from POST request body on wsgi
      controller for TestRun entity added;
    - needed environment variables setting added in nose StoragePlugin;
    - settuping process for HealthCheck updated;
    - integration tests for ostf adapter updated;
    - unit tests also updated;
    - change was tested on deployed env.

    Change-Id: I96580e4e59db0314a75c27f2dda49cf268b05b95
    Closes-Bug: #1281838

Changed in fuel:
status: In Progress → Fix Committed
Changed in fuel:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.