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: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
