Mailing List Archive

some iSCSITarget meta data issues
Hi,

There are couple of issues in iSCSITarget meta-data.

1. there is a extra space in name attribute in status action and it
causes all sort of problems:

<action name="status " <--

what it does, is that crm shell doesn't understand "status " action only
"status", but cib doesn't accept "status". So I can't simply fix it in
the GUI.

And some not very critical...

2. short descriptions are not really short, I think it's not necessary
prepend every one of them with "iSCSI target"

The worst offender
<shortdesc lang="en">Manages an iSCSI target export</shortdesc>

could be changed to "Implementation", or "Daemon Implementation" to be
short and descriptive.

3. defaults are computed in this way that they may be different in
different cluster nodes and may change after the cluster is configured,
which is not very useful in my opinion.

Thanks,
Rasto

--
Dipl.-Ing. Rastislav Levrinc
rasto.levrinc@gmail.com
Linux Cluster Management Console
http://lcmc.sf.net/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On Sat, Feb 25, 2012 at 10:02 AM, Rasto Levrinc <rasto.levrinc@gmail.com> wrote:
> Hi,
>
> There are couple of issues in iSCSITarget meta-data.
>
> 1. there is a extra space in name attribute in status action and it
> causes all sort of problems:
>
> <action name="status " <--
>
> what it does, is that crm shell doesn't understand "status " action only
> "status", but cib doesn't accept "status". So I can't simply fix it in
> the GUI.

Fixed in the metadata:

https://github.com/ClusterLabs/resource-agents/commit/ebb5e5d103066cb19b46427ef0f28937f4943dbe

However, iirc RAs expose "status" operation only for age-old
compatibility reasons, and Pacemaker only ever uses "monitor". Which
is why, I guess, no-one has run into this problem before. Any reason
for LCMC to use "status" at all?

> And some not very critical...
>
> 2. short descriptions are not really short, I think it's not necessary
> prepend every one of them with "iSCSI target"
>
> The worst offender
> <shortdesc lang="en">Manages an iSCSI target export</shortdesc>
>
> could be changed to "Implementation", or "Daemon Implementation" to be
> short and descriptive.

Yeah, that one was just a copy & paste error. Fixed too, thanks.

About the others, I can only surmise you're bikeshedding -- those look
fine to me. However, I'll be happy to take a patch if you have better
suggestions.

> 3. defaults are computed in this way that they may be different in
> different cluster nodes and may change after the cluster is configured,
> which is not very useful in my opinion.

That was my way of trying to provide a "reasonable" default across
distros. The alternative would be that every distro packager would
have to patch the RA to provide the proper default for their platform
-- which would be tgt for RHEL/CentOS, iet for SLES 11 and then lio
for SLES 11 SP2+ (I think), undefined for Debian. You get the picture.
I think the existing way of figuring out the defaults is saner, if not
perfect. Feel free to convince me otherwise, though.

Cheers,
Florian

--
Need help with High Availability?
http://www.hastexo.com/now
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On Sun, Feb 26, 2012 at 1:19 PM, Florian Haas <florian@hastexo.com> wrote:
> On Sat, Feb 25, 2012 at 10:02 AM, Rasto Levrinc <rasto.levrinc@gmail.com> wrote:
>> Hi,
>>
>> There are couple of issues in iSCSITarget meta-data.
>>
>> 1. there is a extra space in name attribute in status action and it
>> causes all sort of problems:
>>
>> <action name="status " <--
>>
>> what it does, is that crm shell doesn't understand "status " action only
>> "status", but cib doesn't accept "status". So I can't simply fix it in
>> the GUI.
>
> Fixed in the metadata:
>
> https://github.com/ClusterLabs/resource-agents/commit/ebb5e5d103066cb19b46427ef0f28937f4943dbe
>

Thanks.

> However, iirc RAs expose "status" operation only for age-old
> compatibility reasons, and Pacemaker only ever uses "monitor". Which
> is why, I guess, no-one has run into this problem before. Any reason
> for LCMC to use "status" at all?

It doesn't. The LCMC does skip the "status" action exactly that reason
by default, but it doesn't skip the "status " (with space) action.
Reason for that, is that anytime new actions show up in the future, I
don't have to change the code at all.

>
>> And some not very critical...
>>
>> 2. short descriptions are not really short, I think it's not necessary
>> prepend every one of them with "iSCSI target"
>>
>> The worst offender
>> <shortdesc lang="en">Manages an iSCSI target export</shortdesc>
>>
>> could be changed to "Implementation", or "Daemon Implementation" to be
>> short and descriptive.
>
> Yeah, that one was just a copy & paste error. Fixed too, thanks.
>
> About the others, I can only surmise you're bikeshedding -- those look
> fine to me. However, I'll be happy to take a patch if you have better
> suggestions.

I think, I'm never bikeshedding. :) It is a mirror issue but the "iSCSI
target" in every short description is redundant, since they all belong
to the iSCSI target RA, and because the long descriptions are cut in the
display, then they all look like "iSCSI target..." and you must mouse
over to actually see what they are. I am exaggerating a bit here. So I
propose as general style rule, don't include RA name to the short
descriptions.

>
>> 3. defaults are computed in this way that they may be different in
>> different cluster nodes and may change after the cluster is configured,
>> which is not very useful in my opinion.
>
> That was my way of trying to provide a "reasonable" default across
> distros. The alternative would be that every distro packager would
> have to patch the RA to provide the proper default for their platform
> -- which would be tgt for RHEL/CentOS, iet for SLES 11 and then lio
> for SLES 11 SP2+ (I think), undefined for Debian. You get the picture.
> I think the existing way of figuring out the defaults is saner, if not
> perfect. Feel free to convince me otherwise, though.


You are right about that. The problem I am having is, that they are two
types of defaults, that you can't distinguish just by looking in the
meta-data.

The first is that are used by RA, so you don't have to define 20
parameters, only if you want use something other than the default. This
is the most common use.

The second type is a suggested value, that is advertised as a default,
but unless it is stored like normal value in the cib, it is not used by
the RA.

The third type is a combination from the two above, like iSCSITarget.

I am solving it by keeping track of the RAs, what kind of defaults they
are using for now, but I'd preferred that there was some consistency in
it.

Rasto

--
Dipl.-Ing. Rastislav Levrinc
rasto.levrinc@gmail.com
Linux Cluster Management Console
http://lcmc.sf.net/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On 02/26/12 15:31, Rasto Levrinc wrote:
> I think, I'm never bikeshedding. :) It is a mirror issue but the "iSCSI
> target" in every short description is redundant,

Which RA are you looking at? iSCSITarget supports 8 different
parameters; 4 of them have "iSCSI target" in their shortdesc. That's
hardly "every short description".

> since they all belong
> to the iSCSI target RA, and because the long descriptions are cut in the

Now what, are you talking about longdesc or shortdesc?

> display, then they all look like "iSCSI target..." and you must mouse
> over to actually see what they are. I am exaggerating a bit here. So I
> propose as general style rule, don't include RA name to the short
> descriptions.
>
>>
>>> 3. defaults are computed in this way that they may be different in
>>> different cluster nodes and may change after the cluster is configured,
>>> which is not very useful in my opinion.
>>
>> That was my way of trying to provide a "reasonable" default across
>> distros. The alternative would be that every distro packager would
>> have to patch the RA to provide the proper default for their platform
>> -- which would be tgt for RHEL/CentOS, iet for SLES 11 and then lio
>> for SLES 11 SP2+ (I think), undefined for Debian. You get the picture.
>> I think the existing way of figuring out the defaults is saner, if not
>> perfect. Feel free to convince me otherwise, though.
>
>
> You are right about that. The problem I am having is, that they are two
> types of defaults, that you can't distinguish just by looking in the
> meta-data.
>
> The first is that are used by RA, so you don't have to define 20
> parameters, only if you want use something other than the default. This
> is the most common use.
>
> The second type is a suggested value, that is advertised as a default,
> but unless it is stored like normal value in the cib, it is not used by
> the RA.
>
> The third type is a combination from the two above, like iSCSITarget.
>
> I am solving it by keeping track of the RAs, what kind of defaults they
> are using for now, but I'd preferred that there was some consistency in
> it.

Patches welcome.

Florian

--
Need help with High Availability?
http://www.hastexo.com/now
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On Sun, Feb 26, 2012 at 4:32 PM, Florian Haas <florian@hastexo.com> wrote:
> On 02/26/12 15:31, Rasto Levrinc wrote:
>> I think, I'm never bikeshedding. :) It is a mirror issue but the "iSCSI
>> target" in every short description is redundant,
>
> Which RA are you looking at? iSCSITarget supports 8 different
> parameters; 4 of them have "iSCSI target" in their shortdesc. That's
> hardly "every short description".

This is how my brain remembers it. :)

>
>> since they all belong
>> to the iSCSI target RA, and because the long descriptions are cut in the
>
> Now what, are you talking about longdesc or shortdesc?


I am talking about long shortdescs. E.g.

<shortdesc lang="en">Specifies the iSCSI target implementation ("iet",
"tgt" or "lio").</shortdesc>

is way too long and it abbreviates to something like "Specifies the
iSCSI..." in the GUI. You may not care about this, but many people do.
So I am not nitpicking or anything, this meta-data happens to be my
interface to the resource agents and it used to work quite well in the
past. So generally I think that short-description shouldn't encode that
they specify something, the name of the resource agent and possible
values.

<shortdesc lang="en">Implementation</shortdesc>

or

<shortdesc lang="en">iSCSI target implementation</shortdesc>

would be enough in my opinion and it's nothing shameful to have short
short-descriptions.

Rasto

--
Dipl.-Ing. Rastislav Levrinc
rasto.levrinc@gmail.com
Linux Cluster Management Console
http://lcmc.sf.net/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On 02/27/12 07:38, Rasto Levrinc wrote:
> I am talking about long shortdescs. E.g.
>
> <shortdesc lang="en">Specifies the iSCSI target implementation ("iet",
> "tgt" or "lio").</shortdesc>
>
> is way too long and it abbreviates to something like "Specifies the
> iSCSI..." in the GUI. You may not care about this, but many people do.
> So I am not nitpicking or anything, this meta-data happens to be my
> interface to the resource agents and it used to work quite well in the
> past. So generally I think that short-description shouldn't encode that
> they specify something, the name of the resource agent and possible
> values.
>
> <shortdesc lang="en">Implementation</shortdesc>
>
> or
>
> <shortdesc lang="en">iSCSI target implementation</shortdesc>
>
> would be enough in my opinion and it's nothing shameful to have short
> short-descriptions.

So you're proposing either a shortdesc that's _identical_ to the
parameter name -- doesn't do a fat lot of good -- or one that contains
the parameter name plus the string "iSCSI target" which you've been
complaining about upthread? Does not compute.

Let me suggest that this discussion is getting us nowhere. The
shortdescs stay as they are until someone comes up with a real improvement.

Thanks for reporting the other issues, though.

Cheers,
Florian

--
Need help with High Availability?
http://www.hastexo.com/now
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On Mon, Feb 27, 2012 at 8:14 AM, Florian Haas <florian@hastexo.com> wrote:
> On 02/27/12 07:38, Rasto Levrinc wrote:
>> I am talking about long shortdescs. E.g.
>>
>> <shortdesc lang="en">Specifies the iSCSI target implementation ("iet",
>> "tgt" or "lio").</shortdesc>
>>
>> is way too long and it abbreviates to something like "Specifies the
>> iSCSI..." in the GUI. You may not care about this, but many people do.
>> So I am not nitpicking or anything, this meta-data happens to be my
>> interface to the resource agents and it used to work quite well in the
>> past. So generally I think that short-description shouldn't encode that
>> they specify something, the name of the resource agent and possible
>> values.
>>
>> <shortdesc lang="en">Implementation</shortdesc>
>>
>> or
>>
>> <shortdesc lang="en">iSCSI target implementation</shortdesc>
>>
>> would be enough in my opinion and it's nothing shameful to have short
>> short-descriptions.
>
> So you're proposing either a shortdesc that's _identical_ to the
> parameter name -- doesn't do a fat lot of good -- or one that contains
> the parameter name plus the string "iSCSI target" which you've been
> complaining about upthread? Does not compute.
>
> Let me suggest that this discussion is getting us nowhere. The

So let me explain some more... :)

> shortdescs stay as they are until someone comes up with a real improvement.

I want them to stay as they were, that I could use them as parameter
descriptions in the GUI. In the "implementation" case it could be that it is
the same as the parameter name, or even "iSCSI Target Implementation" would
fit in, in this case.

I don't mind exception here and there, sometimes there is simply not a short
way to describe something, and you can still see what it is with mouse-over,
but to put there some "speech fillers" for no reason, breaks my usage for no
reason.

I can't use parameter names either, they are usually cryptic unix
abbreviations, lower case with underscores that can't be localized.

If you want to change that short descriptions should be more verbose, I
guess there's nothing I can do, it will be just a small annoyance in couple
of RAs.

Rasto


--
Dipl.-Ing. Rastislav Levrinc
rasto.levrinc@gmail.com
Linux Cluster Management Console
http://lcmc.sf.net/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Re: some iSCSITarget meta data issues [ In reply to ]
On Mon, Feb 27, 2012 at 11:08:47AM +0100, Rasto Levrinc wrote:
> On Mon, Feb 27, 2012 at 8:14 AM, Florian Haas <florian@hastexo.com> wrote:
> > On 02/27/12 07:38, Rasto Levrinc wrote:
> >> I am talking about long shortdescs. E.g.
> >>
> >> <shortdesc lang="en">Specifies the iSCSI target implementation ("iet",
> >> "tgt" or "lio").</shortdesc>
> >>
> >> is way too long and it abbreviates to something like "Specifies the
> >> iSCSI..." in the GUI. You may not care about this, but many people do.
> >> So I am not nitpicking or anything, this meta-data happens to be my
> >> interface to the resource agents and it used to work quite well in the
> >> past. So generally I think that short-description shouldn't encode that
> >> they specify something, the name of the resource agent and possible
> >> values.
> >>
> >> <shortdesc lang="en">Implementation</shortdesc>
> >>
> >> or
> >>
> >> <shortdesc lang="en">iSCSI target implementation</shortdesc>
> >>
> >> would be enough in my opinion and it's nothing shameful to have short
> >> short-descriptions.
> >
> > So you're proposing either a shortdesc that's _identical_ to the
> > parameter name -- doesn't do a fat lot of good -- or one that contains
> > the parameter name plus the string "iSCSI target" which you've been
> > complaining about upthread? Does not compute.
> >
> > Let me suggest that this discussion is getting us nowhere. The
>
> So let me explain some more... :)
>
> > shortdescs stay as they are until someone comes up with a real improvement.
>
> I want them to stay as they were, that I could use them as parameter
> descriptions in the GUI. In the "implementation" case it could be that it is
> the same as the parameter name, or even "iSCSI Target Implementation" would
> fit in, in this case.
>
> I don't mind exception here and there, sometimes there is simply not a short
> way to describe something, and you can still see what it is with mouse-over,
> but to put there some "speech fillers" for no reason, breaks my usage for no
> reason.
>
> I can't use parameter names either, they are usually cryptic unix
> abbreviations, lower case with underscores that can't be localized.
>
> If you want to change that short descriptions should be more verbose, I
> guess there's nothing I can do, it will be just a small annoyance in couple
> of RAs.

I'd say that Rasto has right here. Is there a significant
difference between the two:

<shortdesc lang="en">Specifies the iSCSI target implementation
("iet", "tgt" or "lio").</shortdesc>

<shortdesc lang="en">iSCSI target implementation ("iet", "tgt" or "lio")</shortdesc>

Isn't "Specifies" unnecessary? What purpose a parameter has other
than to specify something?

I'd also vote to drop '("iet", "tgt" or "lio")' too, it belongs
to the long description.

Cheers,

Dejan


> Rasto
>
>
> --
> Dipl.-Ing. Rastislav Levrinc
> rasto.levrinc@gmail.com
> Linux Cluster Management Console
> http://lcmc.sf.net/
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/