Bug 1177800

Re-targeting to 3.6 since this is an RFE. Not sure it's worth to be in 3.5.1. Scott?

Nir, looking at your comments in http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/storage/iscsi.py,cm I think we should discuss how to change the list in this bug.

(In reply to Sandro Bonazzola from comment #2)
> Nir, looking at your comments in
> http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/
> storage/iscsi.py,cm I think we should discuss how to change the list in this
> bug.

I provided the info in my comment:
http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/storage/iscsi.py,cm

Not clear what other info you need.

(In reply to Elad from comment #0)

Looks good, providing what we get in engine when you add/edit iscsi/fcp
storage domain. However it will be hard to include all values in the shell,
so I think we should pick only the most important items: GUID, size,
vendor id and prodcut id.

It will also be useful to show status of paths if some of the paths are
not active.

Note also that size should use G and not MB - this is the smallest unit
users care about.

[ INFO  ] Connecting to the storage server
          The following luns have been found on the requested target:

           1  360060160f4a030008b5463fdf56fe411  70G  DGC/VRAID
              7 paths active

           2  360060160f4a030008b5463fdf56fe411  50G  DGC/VRAID
              6 paths active, 1 failed

If we want all info we can do something like this:

[ INFO  ] Connecting to the storage server
          The following luns have been found on the requested target:

           1  360060160f4a030008b5463fdf56fe411  70G
              vendor: DGC
              product: VRAID
              serial: SDGC_VRAID_CKM00121000438
              status: 7 paths active

           2  360060160f4a030008b5463fdf56fe411  50G
              vendor: DGC
              product: VRAID
              serial: SDGC_VRAID_CKM00121000439
              status: 6 paths active, 1 failed

I think the 2 lines compatct output is more useful, specially when you
have lot of luns.

On my opinion we still need to found a way to indicate that the first number is simply an internal progressive and it's not related to the LUN number.
Maybe using a letter instead of a number could be a good idea  to avoid any possible confusion between the LUN number and our reference.

Something like:

 [ INFO  ] Connecting to the storage server
          The following luns have been found on the requested target:

           A  360060160f4a030008b5463fdf56fe411  70G  DGC/VRAID
              7 paths active

           B  360060160f4a030008b5463fdf56fe411  50G  DGC/VRAID
              6 paths active, 1 failed

(In reply to Simone Tiraboschi from comment #5)
> On my opinion we still need to found a way to indicate that the first number
> is simply an internal progressive and it's not related to the LUN number.
> Maybe using a letter instead of a number could be a good idea  to avoid any
> possible confusion between the LUN number and our reference.
> 
> Something like:
> 
>  [ INFO  ] Connecting to the storage server
>           The following luns have been found on the requested target:
> 
>            A  360060160f4a030008b5463fdf56fe411  70G  DGC/VRAID
>               7 paths active
> 
>            B  360060160f4a030008b5463fdf56fe411  50G  DGC/VRAID
>               6 paths active, 1 failed

Showing numbered list of options is very common, and I don't see why
it wil confuse anyone. If you look in multipath -ll output, you can
see that there is no such thing as lun number there, and I don't think
users are expecting lun number.

To make it even more clear we can use:

[ INFO  ] Connecting to the storage server
          The following luns have been found on the requested target:

           [1]  360060160f4a030008b5463fdf56fe411  70G  DGC/VRAID
                7 paths active

           [2]  360060160f4a030008b5463fdf56fe411  50G  DGC/VRAID
                6 paths active, 1 failed

Anyway, changing the way list items are numbered is easy. The best way
to choose is to get some users using this code and check if it works
for them.

Automated message: can you please update doctext or set it as not required?

Tested using ovirt 3.6.0-1 on iSCSI and on FC.

User gets the following information as part of the LUNs list:

LUN ID, size in GB, vendor, paths and product ID:



[1]     3514f0c5447601164       53GiB   XtremIO XtremApp
                        status: used, paths: 1 active

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

https://rhn.redhat.com/errata/RHEA-2016-0375.html