Bug 1379306

Summary: On provider creation the authentication status is False
Product: Red Hat CloudForms Management Engine Reporter: Jaroslav Henner <jhenner>
Component: ProvidersAssignee: Marcel Hild <mhild>
Status: CLOSED NOTABUG QA Contact: Dave Johnson <dajohnso>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: fsimonce, hkataria, jfrey, jhardy, mpovolny, obarenbo
Target Milestone: GA   
Target Release: 5.7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-24 11:35:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Attachments:
Description Flags
default_auth_status is false none

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