Re: [PATCH pve-cluster 2/2] api: cluster config: create new clusters with lower token coefficient

[Maximiliano Sandoval <m.sandoval@proxmox.com>]

Thomas Lamprecht <t.lamprecht@proxmox.com> writes:

> Am 16.02.26 um 17:00 schrieb Maximiliano Sandoval:
>>> +            'token-coefficient' => {
>>> +                type => 'integer',
>>> +                description => "Token coefficient to set in the corosync configuration.",
>>> +                default => 125,
>>> +                minimum => 0,
>>>From man 5 corosync.conf's token_coefficient documentation: "This value
>> can be set to 0 resulting in effective removal of this feature.". If we
>> want to expose setting this to 0 I would document that it has a special
>> meaning and what does this entail. I would personally feel more
>> comfortable setting `minimum => 1` for now instead.
>
> At least a "see `man 5 corosync.conf` for details might be nice, adding some
> extra hints here, like how it's roughly used and special values, could be
> indeed nice too; some of that might be better off in the docs or the
> verbose_descriptions property though.
>
> But I'm not so sure about the actual value to the user of restricting this
> here? I mean, if we ever would expose this in the UI in some advanced section
> then one could show clear hints for such special/odd values and their potential
> implications, for the CLI that's mostly the job of the docs and maybe an extra
> informal "log" print, but forcing a user editing the corosync.conf manually in
> case they want to try this, whyever that might be, seems to rather worsen UX not
> improve it.

>From corosync.conf(5) I wrongly got the feeling that `0` had some
special-casing going on, but it actually does not. The docs just say in
a somewhat verbose fashion that multiplying with zero generally results
in zero.

We discussed this off-list a bit and my suggestion in my other reply,
namely:

"Coefficient used to determine Corosync's token timeout. See the
corosync.conf(5) manual for more details."

is OK.

-- 
Maximiliano