Description of problem: On /ops/explorer page(Configuration page) in OPS UI, we have a setting called "VMware Console Support" under which I can select "VMware VMRC plugin", "VNC" or "VMware WebMKS". Until 5.8.2.3, if OPS UI was defaulted to "VMware VMRC plugin". Now if I create a service and provision a vm using that service, then go to SSUI, login and try to Access VM Console for the VM provisioned under the service, I used to see "VNC" console for that VM. Note, OPS UI was set to VMRC, so if I open the VM Console for same VM in OPS UI, it would open VMRC Console and Service UI would open VNC Console. In 5.9.0.13, this behaviour changed. As follows: -> OPS UI VMware Console Support set to = VNC, Service UI VM Console button Enabled and can be clicked to access VM Console and it would open VNC/HTML5 console. -> OPS UI VMware Console Support set to = VMware VMRC, Service UI VM Console button Disabled and can not be clicked to access, and user no longer has ability to Access the VM Console. If user of Service UI wants to use VM Console, OPS UI user needs to sacrifice his favourite Console type and choose "VNC" over other console type. So this is as good as not providing any choice to OPS UI user. So this connection/relationship/linkage between VMware Console Support setting from OPS UI and Enabled/Disabled status of Console button in Service UI, was not there previously. And Ideally it should not be there. There should be no relation between OPS UI VMware console support Config and SSUI VM Console button. Historically, a per 5.8, OPS UI could choose anything for VMware console support without worrying about breaking Service UI VM Console button. Service UI VM Console button was always defaulted to VNC. Version-Release number of selected component (if applicable): 5.9.0.13, 5.8.2.3 How reproducible: 100% Steps to Reproduce: 1.Create 2 appliances, CFME 5.9.0.13 and CFME 5.8.2.3 2.Add VMware 5.5 or 6.0 provider to both 3.Create a service catalog and catalog item in both appliances 4.Order the service on both 5.Once both appliances have VMs provisioned using service, navigate to Service UI for both appliances 6.Open service details page 7.Click Access-> VM Console on both Actual results: 5.8.2.3 will have VM Console button clickable and will open VNC Console 5.9.0.13 will NOT have VM Console button clickable. Expected results: 5.9 should behave exactly as 5.8 Additional info: If you need appliances ping me on IRC or request NeedInfo. Also, please note the VMware Console Support on /ops/explorer(Configuration page) is set to "VMware VMRC Console" for both the appliances.
Created attachment 1367589 [details] Shows value of VMware Console Support and Appliance Version
Created attachment 1367590 [details] Shows VM console button in Service UI for appliance version 5.8 and 5.9
I believe this change in behavior is intended - see https://bugzilla.redhat.com/show_bug.cgi?id=1515431 since we can no longer provide vmware webkms we have to check if its present on not (user need to install it). Do you agree that in light of that this is not a bug?
I do understand what changes have been made to WebMKS. But that is not the point here. What I really want to point out is the Behavior changed between 5.8 and 5.9. And, that is a bug, in my perspective because think about SSUI user, he is out of luck if the OPS UI sets the console type to something other than VNC. I want to make sure that SSUI user is NOT affected by what OPS UI user selects in the Config. I do not agree to Disablement of the VM Console button altogether based on OPS UI config. This is wrong also because we are disabling the VM Console button in SSUI eventhough that VM supports the console. Here we have a connection between OPS UI and Service UI which never existed before and the behavior is not consistent between the two UIs.
Okie dokie, we have a pr out there for adding messages to the buttons when they are present: https://github.com/ManageIQ/manageiq-ui-service/pull/1354
This bug is also present in 5.8.3, please clone it for 5.8 stream. -KK.
PR has been updated to include back to fine flag, SHOULD backport with no collisions.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days