Re: [ClusterLabs] Coming in 2.0.2: check whether a date-based rule is expired
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ý schrieb am 24.04.2019 um 02:01 in Nachricht <20190424000144.ga23...@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) pgpPlgorxPO44.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Coming in 2.0.2: check whether a date-based rule is expired
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 [-d ] [-X ] > > 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) pgpmHD73aIt_q.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Coming in 2.0.2: check whether a date-based rule is expired
Hi all, I wanted to point out an experimental feature that will be part of the next release. We are adding a "crm_rule" command 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. We don't automatically remove such constraints, for several reasons: we try to avoid modifying any user-specified configuration; expired constraints are useful context when investigating an issue after it happened; and crm_simulate can be run for any configuration for an arbitrary past date to see what would have happened at that time. 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 [-d ] [-X ] 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). If you give it -X, it will look for the rule in the given XML rather than the CIB (you can also use "-X -" to read the XML from standard input). Example output: % crm_rule -r my-current-rule Rule my-current-role is still in effect % crm_rule -r some-long-ago-rule Rule some-long-ago-rule is expired % crm_rule -r some-future-rule Rule some-future-rule has not yet taken effect % crm_rule -r some-recurring-rule Could not determine whether rule some-recurring-rule is expired Scripts can use the exit status to distinguish the various cases. The command will be considered experimental for the 2.0.2 release; its interface and behavior may change in future versions. The current implementation has a limitation: the rule may contain only a single date_expression, and the expression's operation must not be date_spec. Other capabilities may eventually be added to crm_rule, for example the ability to evaluate the current value of any cluster or resource property. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
