Bug 1149466

Created attachment 944012 [details]
Template UI issues #2

Regarding 1st issue: "Aligning the various text fields and dropdown menus next to their descriptions will help readability (Name, Description, Comment, Cluster and CPU Profile)" - see bug 1149488 comment #2 - that is a general UI infrastructure design done mainly for overcoming long text in localized languages.

@Einav - do we have by any chance an RFE/general bug for responsive dialogs?

Regarding 2nd issue: "Cluster dropdown menu text is left aligned with no spacing while the CPU Profile dropdown menu text has an initial spacing" - the difference is due to the usage of separate widget designs. The cluster select-box design was introduced as part of instance types UI.

@Einav - iirc, we should have a bug for unifying the select-boxes designs?

Regarding the rest of the issues:
@Einav/Eldan - what do you think?

(In reply to Daniel Erez from comment #2)
> Regarding 1st issue: "Aligning the various text fields and dropdown menus
> next to their descriptions will help readability (Name, Description,
> Comment, Cluster and CPU Profile)" - see bug 1149488 comment #2 - that is a
> general UI infrastructure design done mainly for overcoming long text in
> localized languages.
> 
> @Einav - do we have by any chance an RFE/general bug for responsive dialogs?

see my answer in bug 1149488, comment #4. 

> 
> Regarding 2nd issue: "Cluster dropdown menu text is left aligned with no
> spacing while the CPU Profile dropdown menu text has an initial spacing" -
> the difference is due to the usage of separate widget designs. The cluster
> select-box design was introduced as part of instance types UI.
> 
> @Einav - iirc, we should have a bug for unifying the select-boxes designs?

I can't find one, you can open one, if needed. again, there is a good chance that this will be taken care of only once dialogs will adopt the PatternFly design. 

right now it doesn't seem like PatternFly [1] / Bootstrap [2] are supporting the kind of "double-data"-drop-downs that we are supporting [http://i.imgur.com/5zd6NPf.png]. we may need to find another way for displaying this data that will be PatternFly-compatible (i.e. we will adjust out design to PatternFly) or to introduce a new Pattern for this kind of "double-data"-drop-downs (i.e. PatternFly will adjust itself to our design). 

[1] https://www.patternfly.org/widgets/#dropdowns
[2] http://getbootstrap.com/components/#dropdowns

> 
> Regarding the rest of the issues:
> @Einav/Eldan - what do you think?

> - Create as a Sub Template version -> Create as a sub-template version

should probably be "Create as a Template Sub Version" (or "Create as a Sub Version" or "Create as a Sub Version of an Existing Template") in order to conform to the field-name in the 'New VM' dialog ("Template Sub Version)"

> - Disks Allocation -> Disk Allocation

not sure I agree; the template may contain multiple disks, and we are dealing with allocation for all of those Disks. However, 'Disks Allocation' may just be bad English and 'Disk Allocation' may be the correct form, even when pertaining to multiple disks - I honestly don't know. Need an English native speaker to chime in. 

> - Too much spacing underneath the Disks Allocation table headers (Alias,
> Virtual Size, Target and Disk Profile)

can't reproduce: in your screen-shot, it looks like the header-text is not vertically-centralized (i.e. "stuck" to the header-top), therefore it seems that there is too much spacing underneath the header-text. in my setup (latest 'master', client is F20/FF33) the header-text is vertically-centralized within the header so it looks OK - even the strange double-separator between grid-columns is not there - see http://i.imgur.com/HlCMt9b.png. 

> - The Disks Allocation table is very small and the various fields do not
> fully use up their allotted space, causing usability issues, recommend
> setting dialog size higher on start-up.  The Virtual Size column can also be
> narrower

agree; the dialog can definitely be wider in order to better accommodate the Disks Allocation table; I wouldn't touch the Virtual Size column-width only due to localization considerations (i.e. 'Virtual Size' may be a longer string in some of the non-English locales). 

> - Disks’ Storage Domains are not accessible -> Disk Storage Domains are not
> accessible OR Storage Domains connected to the Disks are not accessible

the current phrasing is the most accurate one. 
'Disk Storage Domain' (a) has a singular reference, which may be wrong in case there are 2 disks or more and (b) implies that the Storage Domains belong to the Disk, which is incorrect. 
'Storage Domains connected to the Disks' is wrong; if anything, the Storage Domains contain the Disks. 
So another correct phrasing can be "The Storage Domains that contain the Disks are not accessible"; however, to me - this doesn't sound better than the current phrasing.

Thanks Einav!

> 
> > - Disks Allocation -> Disk Allocation
> 
> not sure I agree; the template may contain multiple disks, and we are
> dealing with allocation for all of those Disks. However, 'Disks Allocation'
> may just be bad English and 'Disk Allocation' may be the correct form, even
> when pertaining to multiple disks - I honestly don't know. Need an English
> native speaker to chime in. 

@Scott/Sean - what do you think?

Daniel, can you clarify the chain of dependencies here please?

I see to patches merged upstream, and this BZ depending on two other BZs in status NEW.
Do these patches fix the issue?
Part of it?

(In reply to Allon Mureinik from comment #5)
> Daniel, can you clarify the chain of dependencies here please?
> 
> I see to patches merged upstream, and this BZ depending on two other BZs in
> status NEW.
> Do these patches fix the issue?
> Part of it?

This bug includes various issues, each is addressed individually:
* http://gerrit.ovirt.org/34798 covers issue: "Create as a Sub Template version -> Create as a sub-template version"
* http://gerrit.ovirt.org/34799 covers issue: "The Disks Allocation table is very small and the various fields do not fully use up their allotted space, causing usability issues, recommend setting dialog size higher on start-up."
* bug 1160307 and bug 1160393 should cover the remaining unresolved issues.

(In reply to Daniel Erez from comment #4)
> Thanks Einav!
> 
> > 
> > > - Disks Allocation -> Disk Allocation
> > 
> > not sure I agree; the template may contain multiple disks, and we are
> > dealing with allocation for all of those Disks. However, 'Disks Allocation'
> > may just be bad English and 'Disk Allocation' may be the correct form, even
> > when pertaining to multiple disks - I honestly don't know. Need an English
> > native speaker to chime in. 

@Scott/Sean - what do you think?

Julie, can you weigh in here please?

(In reply to Daniel Erez from comment #7)
> (In reply to Daniel Erez from comment #4)
> > Thanks Einav!
> > 
> > > 
> > > > - Disks Allocation -> Disk Allocation
> > > 
> > > not sure I agree; the template may contain multiple disks, and we are
> > > dealing with allocation for all of those Disks. However, 'Disks Allocation'
> > > may just be bad English and 'Disk Allocation' may be the correct form, even
> > > when pertaining to multiple disks - I honestly don't know. Need an English
> > > native speaker to chime in. 
> 
> @Scott/Sean - what do you think?

"Disk Allocation" would be the more accepted term in American English.  It actually refers to an action of an object type, which is often just referred to as a singular object.  Think "Network Allocation", "Server Provisioning", etc.

This depends on an RFE that was pushed out to 4.0 - pushing this one too.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Moving out all non blocker\exceptions.

Please check latest 4.2 code dialog, as some of it was improved.

The dialog looks fine to me in the new 4.2 UI.
The recent patch (https://gerrit.ovirt.org/#/c/79553) fixes the "Disk[s] Allocation" label issue as per comment 9.

Once it is merged, the BZ can be moved to MODIFIED and QE can verify (or fail) it.

Created attachment 1303476 [details]
new template screen

--------------------------------------
Tested with the following code:
----------------------------------------
ovirt-engine-4.2.0-0.0.master.20170723141021.git463826a.el7.centos.noarch
vdsm-4.20.1-218.git1b7671f.el7.centos.x86_64

Tested with the following scenario:

Steps to Reproduce:
1. Navigate to an existing VM that is powered off
2. Click on the Make Template button
3. Note the dialog that ensues

Actual results:
All issues mentions in comment #1 is fixed

Expected results:

Moving to VERIFIED!

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Sync with Jira

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days