Inconsistencies in boolean parameter settings of targetcli

[Rufe Glick]

Hello all,

Just a feedback of a newcomer to the targetcli.

Some boolean parameters accept true or false, e.g. 'set global
auto_cd_after_create=true|false'; while other boolean parameters
accept 0 or 1, e.g. 'set attribute authentication=1|0'.

It doesn't bother me much, but it would be nice to eliminate these
inconsistencies. That'll make overall user experience a bit more
smooth and consistent.

The other thing of the same nature is paramter naming. Some of them
come with underscores, e.g. 'set global auto_cd_after_create' and
friends; while others come in camel case, e.g. 'set parameter
AuthMethod'.

Thanks,
Rufe

[Jerome Martin]

Post by Rufe Glick
Hello all,
Just a feedback of a newcomer to the targetcli.
Some boolean parameters accept true or false, e.g. 'set global
auto_cd_after_create=true|false'; while other boolean parameters
accept 0 or 1, e.g. 'set attribute authentication=1|0'.

And there is even Yes|No for RFC-3720 parameters like DataPDUInOrder or
DataSequenceInOrder !!!

The parameters/attributes difference is due to the kernel-side and the
fact that in 2.x series, we simply pass the values through as there is
no way to check the type in a generic manner (see previous posts in this
thread). The targetcli UI attributes format is a decision I made years
ago, perhaps for bad reasons (I hoped to get rid of 0|1 and Yes|No
sooner and unify on a better syntax).

With 3.x and its future configuration shell (for now in early preview),
which will eventually replace the current shell for config, this is
unified as 3.x uses policy files defining unified trypes that get
translated correctly on the kernel side.

Post by Rufe Glick
It doesn't bother me much, but it would be nice to eliminate these
inconsistencies. That'll make overall user experience a bit more
smooth and consistent.

Agreed.

Post by Rufe Glick
The other thing of the same nature is paramter naming. Some of them
come with underscores, e.g. 'set global auto_cd_after_create' and
friends; while others come in camel case, e.g. 'set parameter
AuthMethod'.

Again, this is the kernel-side naming of things. AFAIK, only RFC-3720
parameters use camel case. On this front, I have no solution yet, and am
not too sure it is overall desirable (naming consistency vs consistency
with the kernel side, 3rd party scripts and legacy rtslib scripts). I'll
keep that in mind though.