Created attachment 1265351 [details] logs and screenshots Description of problem: when we select a template we do not see the required info Objects Kind Name Service ${NAME} Route ${NAME} ImageStream cfme-openshift-app PersistentVolumeClaim ${DATABASE_SERVICE_NAME} PersistentVolumeClaim ${NAME} DeploymentConfig ${NAME} Service ${MEMCACHED_SERVICE_NAME} ImageStream cfme-openshift-memcached DeploymentConfig ${MEMCACHED_SERVICE_NAME} Service ${DATABASE_SERVICE_NAME} ImageStream cfme-openshift-postgresql DeploymentConfig ${DATABASE_SERVICE_NAME} Version-Release number of selected component (if applicable): cfme-5.8.0.7-1.el7cf.x86_64 working on podfied cfme How reproducible: 100% Steps to Reproduce: 1. deploy cfme (I work on a ppodfied cfme) 2. add a container provider (my case it's openshift 3.4) 3. navigate to compute -> containers -> container templates -> select a template Actual results: Objects table is not showing info Expected results: info should be presented Additional info:screenshot and logs from container
Zahi I think we already had a discussion related to this somewhere (can you have a reference here? link, etc...) We should probably improve the naming or how we display these because it's confusing.
This appears to be mis-filed, sending to UI - OPS team.
(In reply to Federico Simoncelli from comment #1) > Zahi I think we already had a discussion related to this somewhere (can you > have a reference here? link, etc...) > > We should probably improve the naming or how we display these because it's > confusing. Federico, you are right. We had a short discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1391683. We agreed that the user should see the variable names because the values are filled in by the server during instantiation, and closed the BZ as NOTABUG. Do you want to consider a different approach here?
(In reply to zakiva from comment #5) > Do you want to consider a different approach here? Yes we'll have to come up with a naming for the column or some other UI/UX hint to make it easier to understand that these are variables.
https://github.com/ManageIQ/manageiq-ui-classic/pull/1147
(In reply to zakiva from comment #7) > https://github.com/ManageIQ/manageiq-ui-classic/pull/1147 Dafna can you confirm that this is clear enough for you now? Or suggest a different naming.
based on your explanation and the screenshot you attached, I would suggest following changes to make it clearer: "objects" = "Object parameters" "Kind" = "object" "name" = "object implementation" (or just "implementation") Another suggestion I have is that since most of the UI is actual fixed and is not presented in this way, it may save some time for others to add a little tool tip explaining that the values are filled in by the server during instantiation and this table presents the values. side note - a nice RFE for the future would be to actually link the presented variables with the existing available objects (i.e $node would be linked to container nodes summary page).
Zahi, is it possible to add a note under the table saying: "The values above may contain variable parameters that are filled in at instantiation".
(In reply to Federico Simoncelli from comment #10) > Zahi, is it possible to add a note under the table saying: "The values above > may contain variable parameters that are filled in at instantiation". Added a note please see screenshot in the PR https://github.com/ManageIQ/manageiq-ui-classic/pull/1147
Verified. Side note added as per comment 11