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

[Jan Pokorný]

On 24/04/19 08:22 +0200, Ulrich Windl wrote:
> 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... ;-)

Hehe, and be aware that pacemaker already started the tradition of
pioneering some innovative time expresssions, so don't say it too
loudly:

$ iso8601 -d epoch
> Date: 1970-01-01 00:00:00Z

Mostly as a follow-up for the above joke, please don't _ever_ refer
to "epoch" as a date/time expression, it may go away any time without
notice (or on relatively short notice, for being undue here).

>>>> 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:
>>> 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)
> 
>> 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 

FWIW. I now think we should leverage gnulib's parse-datetime module
directly:
https://github.com/ClusterLabs/pacemaker/pull/1756#issuecomment-486108864

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190424/c64e1638/attachment.sig>