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)
pgpmHD73aIt_q.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/