Bug 1379306 - On provider creation the authentication status is False
Summary: On provider creation the authentication status is False
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: unspecified
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: GA
: 5.7.0
Assignee: Marcel Hild
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-26 10:38 UTC by Jaroslav Henner
Modified: 2017-12-05 15:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-24 11:35:09 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:


Attachments (Terms of Use)
default_auth_status is false (602.54 KB, image/png)
2016-09-26 10:44 UTC, Jaroslav Henner
no flags Details

Description Jaroslav Henner 2016-09-26 10:38:42 UTC
Description of problem:
Right after creation _and validation_ of the container provider, when clicking on the edit (using Selenium), the page requires validation again. This is probably because the page ajax-loads the url https://$CFME/ems_container/ems_container_form_fields/$NUM where transiently the default_auth_status is False sometimes.

This breaks automation as it is then impossible to update the container provider (the validation is required).


Version-Release number of selected component (if applicable):
cfme 5.6.2.0.20160913114355_70e9086


How reproducible:
rarely 1/15

Steps to Reproduce:
1. Set-up https://github.com/ManageIQ/integration_tests
2.
import cfme.fixtures.pytest_selenium as sel
from utils import providers, version, conf
from cfme.configure import configuration 
conf.env['base_url'] = CFME_URL

from uuid import uuid4
from utils.update import update
p=providers.get_crud("cm-env2")
for i in range(15):
    if p.exists:
        p.delete(cancel=False)
        p.wait_for_delete()
    p.create()
    #sleep(10)
    with update(p):
        p.name="{}".format(uuid4())


Actual results:
Right after the container provider creation the Web UI thinks we are not authenticated to the container provider, but after a while all it changes it's mind and has no problems with the authentication

Expected results:
Once the provider is created and validated with correct token, the default_auth_status should be True

Additional info:

Comment 2 Jaroslav Henner 2016-09-26 10:44:01 UTC
Created attachment 1204776 [details]
default_auth_status is false

Comment 6 Marcel Hild 2016-11-24 11:35:09 UTC
Like Federico hinted the process of creating a provider via the UI is queued.
So, although you hit `validate`, which your automation tools do, the provider is created with an authentication_status of 'None'. The authentication check is put on the queue and is processed asynchronously.
So your best bet is indeed to put either a sleep into automation or somehow check the validation status. Unfortunately the latter one is not possible via the rest api

So I'm closing this as NOTABUG


Note You need to log in before you can comment on or make changes to this bug.