Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1513052 - Smartstate Analysis greyed out on workers not in a provider zone (webui zone)
Summary: Smartstate Analysis greyed out on workers not in a provider zone (webui zone)
Status: CLOSED DUPLICATE of bug 1513053
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: SmartState Analysis
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: cfme-future
Assignee: Rich Oliveri
QA Contact: Dave Johnson
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-14 16:30 UTC by Lynn Dixon
Modified: 2018-05-08 13:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-07 19:27:13 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

Description Lynn Dixon 2017-11-14 16:30:40 UTC
Description of problem:
In an environment with multiple workers, across zones, The button to launch a smart state is greyed out when the user is logged in to a worker thats not in the providers zone. 
Example: a user tries to request a smartstate from a "WebUI" zone with workers ONLY doing web interface.  A "provider" zone for VMware houses all workers that have the smartstate role enabled.  The smartstate button will be greyed out and not available.

I have to login to an appliance in the providers zone to request a smart state, which then works as expected. 

Version-Release number of selected component (if applicable): 
Possibly other versions as well

How reproducible:
Deploy cloudforms with at least two zones, one of those zones setup for webservices only, and the other setup for provider and smartstate operations.  Login to the webui zone and try to request a smartstate.

Steps to Reproduce:
1. Deploy cloudforms, setup two zones. a WebUI zone (with workers only doing web services for UI) and a second zone for provider operations (including workers setup for smartstate in this zone)

2. Configure roles for workers in the webui zone to only have roles relevant for UI work. (User interface, Web Services, Notifier, etc). DO NOT SETUP smartstate role in this zone

3. Configure a provider zone, that includes roles for smartstate and all other relevant roles.  Also fully configure the provider to perform smartstates.

4. Login to a worker in the "WebUI" zone and navigate to a VM.  Click on "Configuration" and try to request a SmartState Analysis. Notice that the button is greyed out.

5. NOW..login to a worker that is in the provider zone, navigate to a VM and request a smartstate.  Notice that the button is no longer greyed out, and you are able to perform a smartstate without issue.

Actual results:
Smartstate button greyed out with hover text "There is no server with the smartstate role enabled" when trying to request smartstate when logged into a worker thats in a "webui" zone. Can only request smartstates when logged into a worker thats in the provider zone

Expected results:
Able to perform smartstate when logged in to workers that are designated as "webui" only workers.

Additional info:

Comment 2 Dave Johnson 2017-11-14 16:44:25 UTC
Please assess the impact of this issue and update the severity accordingly.  Please refer to for a reminder on each severity's definition.

If it's something like a tracker bug where it doesn't matter, please set the severity to Low.

Comment 3 Lynn Dixon 2017-11-27 14:05:46 UTC
NOt sure why this one exists?  The BZ with all the conversations is here:

Changing this priority to match that BZ. That is the original submission.

Comment 5 Rich Oliveri 2018-05-07 19:27:13 UTC
I'm marking this as a duplicate of That BZ is in POST, so the issue should be resolved.

*** This bug has been marked as a duplicate of bug 1513053 ***

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