[ClusterLabs] Antw: Re: Coming in 2.0.2: check whether a date-based rule is expired

[Ulrich Windl]

Hi!

I know that April 1st is gone, but maybe should be have "user-friendly
durations" also? Maybe like:
"a deep breath", meaning "30 seconds"
"a guru meditation", meaning "5 minutes"
"a coffee break", meaning "15 minutes"
"a lunch break", meaning "half an hour"
...

Typical maintenance tasks can be finished within guro meditation or coffee
breaks; only few require lunch breaks or more... ;-)

Regards,
Ulrich

>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 24.04.2019 um 02:01 in
Nachricht
<20190424000144.GA23995 at redhat.com>:
> On 16/04/19 12:38 ‑0500, Ken Gaillot wrote:
>> We are adding a "crm_rule" command
> 
> Wouldn't `pcmk‑rule` be a more sensible command name ‑‑ I mean, why not
> to benefit from not suffering the historical burden in this case, given
> that `crm` in the broadest "almost anything that can be associated with
> our cluster SW" sense is an anachronism, whereas the term metamorphed
> into the invoking name of the original management shell project
> (heck, we don't have `crmd` as daemon name anymore)?
> 
>> that has the ability to check > whether a particular date‑based rule is
>> currently in effect.
>> 
>> The motivation is a perennial user complaint: expired constraints
>> remain in the configuration, which can be confusing.
>> 
>> [...]
>> 
>> The new command gives users (and high‑level tools) a way to determine
>> whether a rule is in effect, so they can remove it themselves, whether
>> manually or in an automated way such as a cron.
>> 
>> You can use it like:
>> 
>>     crm_rule ‑r <rule‑id> [‑d <date>] [‑X <rule‑xml>]
>> 
>> With just ‑r, it will tell you whether the specified rule from the
>> configuration is currently in effect. If you give ‑d, it will check as
>> of that date and time (ISO 8601 format).
> 
> Uh, the date‑time data representations (encodings of the singular
> information) shall be used with some sort of considerations towards the
> use cases:
> 
> 1. _data‑exchange friendly_, point‑of‑use‑context‑agnostic
>    (yet timezone‑respecting if need be) representation
>    ‑ this is something you want to have serialized in data
>      to outlive the code (extrapolated: for exchange between
>      various revisions of the same code)
>    ‑ ISO 8601 fills the bill
> 
> 2. _user‑friendly_, point‑of‑use‑context‑respecting representation
>    ‑ this is something you want user to work with, be it the
>      management tools or helpers like crm_rule
>    ‑ ISO 8601 _barely_ fills the bill, fails in basic attampts of
>      integration with surrounding system:
> 
> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \
>     ‑r rule.auto‑2 ‑d "next Monday 12:00"
>> (crm_abort) 	error: crm_time_check: Triggered assert at
iso8601.c:1116 : 
> dt‑>days > 0
>> (crm_abort) 	error: parse_date: Triggered assert at iso8601.c:757 :

> crm_time_check(dt)
> 
>      no good, let's try old good coreutils' `date` as the "chewer"
> 
> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \
>     ‑r rule.auto‑2 ‑d "$(date ‑d "next Monday 12:00")"
>> (crm_abort) 	error: crm_time_check: Triggered assert at
iso8601.c:1116 : 
> dt‑>days > 0
>> (crm_abort) 	error: parse_date: Triggered assert at iso8601.c:757 :

> crm_time_check(dt)
> 
>      still no good, so after few more iterations:
> 
> $ CIB_file=cts/scheduler/date‑1.xml ./tools/crm_rule ‑c \
>     ‑r rule.auto‑2 ‑d "$(date ‑Iminutes ‑d "next Monday 12:00")"
>> Rule rule.auto‑2 is still in effect
> 
>      that could be much more intuitive + locale‑driven (assuming users
>      have the locales set per what's natural to them/what they are
>      used to), couldn't it?
> 
> I mean, at least allowing `‑d` switch in `crm_rule` to support
> LANG‑native date/time specification makes a lot of sense to me:
> https://github.com/ClusterLabs/pacemaker/pull/1756 
> 
> Perhaps iso8601 (and more?) would deserve the same, even though it
> smells with dragging some compatibility/interoperatibility into the
> game?  (at least, `crm_rule` is at brand new, moreover marked
> experimental, anyway, let's discuss this part at developers ML
> if need be ‑‑ one more thing to possible put on debate, actually,
> this user interface sanitization could be performed merely in the
> opaque management shell wrappings, but if nothing else, it amounts
> to duplication of work and makes bare‑bones use bit of a PITA).
> 
> ‑‑ 
> Jan (Poki)